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PREFACE 


This publication was prepared as a reference handbook for 
the programing personnel of PTS-100 users. It presents the 
information necessary to write programs to be executed on the 
PTS-100 and to use the software support systems provided with 
the PTS-100. The handbook is organized in distinct parts, 


as follows: 


PART 1: This part of the handbook presents a programer 
overview of the PTS-100 operating environment 


and software support available to users of the 
PTS-100. 


PART 2: This part of the handbook presents detailed 
descriptions of the Assembler ianguage and pro- 


graming features available to PTS-100 programers. 


PART 3: Presented in this part of the handbook are "how to 
use'' descriptions of the utility programs supplied 
with the PTS- 100, 


PART 4: This portion of the handbook describes the macro 


library files available to users. 
The Table of Contents on the following page indicates the 


general coverage of information in this handbook. Each of the 


four parts of the handbook includes a detailed table of contents. 
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PART l. 
Section l. 


The Programable Terminal System 100 
(PTS-100) contains a general purpose computer 
consisting of a central processor unit (CPU), a 
modular semiconductor (MOS) main memory ex- 
pandable from 8192 to 65536 bytes, a control 
panel, and both low speed and high speed device 
controllers. A customer engineer's console is 


also optionally available as an expanded console 


for debugging programs. 


The low speed controllers accommodate 


peripheral devices that operate at data transfer 


rates at or below 9600 bits per second, including CRT 


display devices, card readers, serial printers, 
The 


high speed controllers provide interface for pe- 


teletype devices, cassette tape drives, etc. 


ripheral devices that operate at data transfer 
rates Ge excess of 9600 bits per second such as 
disc devices, magnetic tape transports, and host 
computer channel interface devices such as the 
IBM 360/370 multiplexer/selector channel 


interface. 


The memory size and peripheral equipment 
configuration of a given PTS-100 installation are 
flexible so that individual users can select those 
components especially suited to their application 
processing needs, Certain device controllers 
and the peripheral devices that may be attached 
to them are offered to users as "standard" 
equipment. Thatis, standard hardware equip- 
ment is supported by the PTS-100 operating 
system--the Input/Output Control System (IOCS) 
monitor--which interfaces the CPU, I/O devices, 
and the programs to be executed on the PTS-100. 
The IOCS monitor, described in Section 2 follow- 
ing, is specially tailored for each standard PTS- 
100 equipment configuration via the RDS- supplied 
System Generator program, described in Part 3 
of this handbook, and the Assembler program, 


described in Part 2. If nonstandard devices are 
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to be attached to the PTS-100, the user must 
modify the IOCS monitor to accommodate the 
devices, as described in appropriate areas with- 
in this handbook. 


Since the total equipment configuration of a 
PTS-100 installation is user-selected, no 
attempt has been made in this handbook to de- 
scribe the operational characteristics of specific 
devices. For this information, the reader 
should consult the PTS-100 Reference Manual. 
Certain I/O devices are required by various 
software programs offered with the PTS-100, 
as noted in the detailed descriptions of these 


support systems throughout this handbook. 


Regardless of the memory size and types 
of I/O devices attached to a given PTS-100, the 
CPU and the control console are standard for all 
installations. For convenience, information re- 
lating to programing the system and programer 
usage of the CPU and control console is 
presented in summary form on subsequent pages 
of this section. For detailed descriptions of the 
hardware characteristics of these components 
of the PTS-100, see the PTS-100 Reference 


Manual. 


1.1 Central Processor Unit 

The central processor unit (CPU) executes 
programs stored in main memory and controls 
data transfers between main memory and I/O 
devices. The CPU communicates with executing 
programs via registers, four of which are pro- 
gram addressable. CPU communication with 
main memory is via the 16-bit processor 
memory bus (PMB). Communication between 
the CPU and I/O devices takes place over the 


input output bus (IOB). 


The CPU utilizes a 16-bit word, and is 


capable of executing one word (short) or two word 


(long) instructions. Each word is composed of 
two 8-bit bytes, or characters. Memory 
addressing is by word (16 bits) or byte (8 bits). 
The following methods of addressing may be used 


with or without single level indirect miode: 


® Absoluie addressing over the maximum 


memory capacity of 65, 536 bytes. 


e Dynamic page addressing of +128 words 
relative to the program counter register in 
short instructions and 32768 bytes in long 


instructions. 


Indexed addressing via index register l or 
index register 2 of +128 words in short 
instructions or £32768 bytes in long 


instructions. 


A 16-bit byte displacement value is used to 
compute the effective address of long instruc- 
tions, and a 7-bit word displacement value is 
used to compute the effective addresses of 


short instructions. 

CPU instructions are termed "executable." 
That is, they are assembly language statements 
that the Assembler translates to executable © 
machine language format. Executable instruc- 
tions are provided to accomplish the following: 

Arithmetic operations 


Branches in program execution 


Loading CPU registers with data values 


stored in memory locations 


Storing contents of CPU registers in 


memory locations 


Comparative tests of data values 


Logical testing of data values 

Interrupt masking and level changes 

I/O operations 
For a detailed description of executable instruc- 
tions and other Assembler language statements, 


see Part 2 of this handbook. 


The CPU communicates with executing pro- 


grams via registers within itself. Four of the 


registers are program addressable. They are 
the program counter, the accumulator, index 
register 1, and index register 2. These 


registers are described below. 


Pe ee Program Counter (PC) 

The program counter is a 16-bit register 
that supplies the addresses of instructions to be 
fetched from main memory, and hence directs 
the program execution sequence. Normally, as 
an instruction word is fetched the PC contents 
are incremented by 2 to advance the byte- 
oriented address to that of the next program 
instruction word, or the second word of a double 
word instruction. This sequencing is disrupted 
only by the occurrence of a branch instruction or 
the CPU response toa priority interrupt. In the 
first case, if the branch instruction's conditions 
are satisfied, its effective address replaces the 
current PC content and initiates a sequential | 
change in program processing. In the case ofa 
priority interrupt, the CPU hardware automatical- 
ly saves the interrupted program's current PC 
content, and enters the effective address of the 
appropriate IOCS monitor interrupt servicing 
routine in the PC. The interrupt servicing 
routine effects an interrupt return via its last 
executable instruction, which restores the saved 
content of the PC, thus restarting the interrupted 


program at the point of interrupt. 


1.1.2 Accumulator (AC) 


The 16-bit accumulator (AC) register is the 
principal data handling register for the CPU and 
is involved in the execution of most instructions. 
The accumulator's most significant bit (MSB), 
bit 0, is employed as the sign bit (value = 0 for 
positive, and = 1 for negative) for arithmetic 
operations, leaving 15 bits for fixed-point data 
representation of the following range of values: 


215 <nc< 21° - 1 


or, in decimal equivalents: 
-32,768 <n s 32,767 


1.1.3 Index Registers 1 and 2 (X1 and X2) 
Index registers 1 and 2 are both 16-bit 
registers used, primarily, to provide address 

components for the computation of effective 
addresses. They may also be used as temporary 


storage registers for data and address references. 
1,2 Control Panel 


The control panel of the PTS-100 computer 
provides for primary power and initialization of 
computer processing. The power is controlled 


by the POWER ON/OFF switch on the console. 


Initialization of processing is effected by 
depressing the IPL (Initial Program Load) push- 
Whenever the IPL button 
is depressed, a hardwired IPL bootstrap routine 
is activated in the Read Only Memory (ROM). 
The IPL bootstrap routine then performs the 


button on the console. 


following: 


e Clears all main memory locations to zero 


values, 


@ Transfers a section of itself into memory, 


beginning at location zero. 


e Activates the transferred section, which 
then transfers four words (i.e., 64 bits) 
from manually set switches to word locations 


3 through 6 of main memory, and: 


Determines the address of the loading 


device from the first word of switch data 


Issues a read command to the loading 
device to cause the six-byte header 
record of the program to be loaded into 
main memory. The header record con- 


tains the following: 


Load address of the program to 
be loaded 


Byte count (number of characters) 
to be read 


Execution (starting) address of the 
program to be loaded 


Reads one record (the program to be 
loaded) into consecutive memory loca- 
tions, starting at the load address, until 
the number of characters specified by 


the byte count have been loaded. 


Transfers control to the loaded program 
and starts its execution at the starting 


address specified in the header record. 


The Initial Program Load bootstrap is 
required to load a one record binary program 
into PTS-100 memory. Under typical operating 
conditions, the one record binary program is the 
Piggyback Loader, which in turn loads the 
) The Absolute/ 


Relocating Loader must be used to load object 


Absolute/Relocating Loader. 


programs produced by the PTS-100 Assembler. 
Before programs other than the Piggyback 
Loader can be loaded via the IPL button, they 
must have been assembled by the PTS-100 
Assembler, loaded by the Absolute/Relocating 
Loader, and then dumped from main memory to 
a cassette tape or punched paper tape device. 
The procedures for loading and dumping pro- 


grams are described in Part 3 of this handbook. 
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Section 2. 


The operating system of the PTS-100 is the 
Input/Output Control System (IOCS) which moni- 
tors the servicing of interrupts from the multi- 
level interrupt system, described in detail in 
Part 2 of this handbook. That is, the IOCS moni- 
tor optimizes I/O resources in the PTS-100 real 
time interrupt environment by interfacing execut- 
ing programs, the CPU, and I/O devices. For 
any given PTS-100, a specially tailored IOCS is 
created by the System Generator and Assembler 
programs, as described elsewhere in this 


publication. 


The IOCS monitor is composed of two major 
components: the I/O Control Nucleus and the 
Physical I/O Routines. The Nucleus interfaces 


between executing systems and applications pro- 


grams and the Physical I/O Routines, which issue 


I/O commands +0 peripheral devices attached to 
the PTS-100 and receive and initiate processing 
of I/O interrupts from devices in the equipment 
configuration, The interface relationship of the 
executing object programs, the IOCS monitor, 
and the peripheral devices attached to the PTS- 
100 is illustrated in figure 1-i. The structural 
and operating characteristics of the Nucleus and 
the Physical I/O Routines are described in the 


following subsections. 
2.1 I/O Control Nucleus 


The I/O Control Nucleus contains three 


groups of routines: 


® Level Service Routines, which perform the 


following functions: 


Service interrupts from I/O devices and 


object program calls 
Service "unknown" interrupts 


Restore interrupt levels after interrupts 


from other levels have been serviced. 


PTS-100 OPERATING SYSTEM 


ry Monitor Service Call Routines, which per- 
form the processing required to open, close, 
and initialize devices, to perform I/O opera- 
tions, and to exit from the system when 


program processing is completed 


e An optional Monitor Log Service Routine, 
which produces 32-character messages on 


the System Log device. 


Within a given IOCS monitor, one set of 
Level Service Routines (LSRs) is generated for 
each of the interrupt levels 1 - 8. Thatis, these 
routines service interrupts that occur on the 
external (device) interrupt levels 1 - 8, to which 
devices have been previously assigned. Each set 


of LSRs contains the following functional routines: 
A level service entry and save routine 


A linkage to all Device Service Routines 
within the Physical 1/O Routines 


An "unknown!" interrupt handling routine 


A level restore and exit routine. 


For each of the 11 interrupt levels, an 
interrupt packet, described in Part 2 of this hand- 
book, exists in the IOCS monitor. For interrupt 
levels 1 - 8, the starting address of the asso- 
ciated LSR is stored in the interrupt packet asso- 
ciated with the interrupt level. Thus, when an 
interrupt occurs, control is turned over to the 
LSR associated with the level at which the inter- 
rupt occurred. The LSR then transfers control 
to one of the Device Service Routines (DSRs) 
associated with one or more devices assigned to 
the corresponding interrupt level. The DSR that 
receives control checks to see if its associated 
physical I/O device has an interrupt pending. If 
so, the DSR calls the appropriate device driver 
routine to service the interrupt, after which con- 


trol returns to the LSR, which then returns 


ae tee | 


PHYSICAL I/O DEVICES 


DISPLAY 
KEYBOARD 


EXECUTING OBJECT PROGRAMS | IOCS MONITOR | | 


APPLICATIONS 
PROGRAMS — 


CARD 
READER 


I/O CONTROL NUCLEUS 


SYSTEMS 
PROGRAMS 


PHYSICAL I/O ROUTINES 


PRINTER 


DEVICE 


OTHER 1/o / 
DEVICES 


Figure 1-1. Interface Relationship of Executing Programs, IOCS Monitor, and Physical I/O Devices 
in the Equipment Configuration of the PTS-100 


control to the previous interrupt level. If no The routines that may be called by the execu- 
interrupt was pending, the next DSR, if any, on ting program to perform I/O services are the 
the interrupt level is polled. This polling pro- following: 


cedure continues until the interrupting device is : 
es e OPEN routine, which opens a logical unit 


located. If no device on this level issued an ; Fhe ae a ; 

i: ic (i.e., device) by initializing the device and 
interrupt, the unknown interrupt error routine . 
0 . its related software controls so that 1/O 


for this level is entered to log an error message . 
: “ be S operations can subsequently be performed on 


on the System Log device. The level service ; 
the: device 


restore routine then restores the registers of the 


int d m, and returns control to the 
ERNE Gho Anis uireule apenas IO ACTion routine, which responds to and 
interrupt level from which the LSR received ; 

. queues requests for input/output operations 


control. en . 
on specific devices 
The Monitor Service Call (MSC) routines are @e CLOSE routine, which immediately closes a 
entered by the execution of an MSC (i.e., trap) . specific logical unit (i.e. , device) at the end 
instruction within the executing program. MSC of a processing job or to facilitate an error 
routines operate at interrupt priority level 9. recovery 


INITialization routine, which resets all 1/O 


devices on the system 


EXIT routine, which is called when an 
executing program exits from the system. 
This routine issues a message that the pro- 
gram has exited and waits for manual inter- 


vention to specify restart of processing. 


The procedures for calling these routines from 
within the program are described in detail in 
Part 2 of this handbook. 


The Log Service Routine prints monitor 
messages on the System Log device, if the device 
was assigned at system generation time. These 
messages can be used for error logging, operator 
notes, or any other short (i.e., 32-character) 
messages. Monitor message logging does not 
interfere with executing program output of 
messages to the System Log device. In fact, no 


special provisions or precautions need be made 


within the executing object program. 


2.2 Physical I/O Routines 

The Physical 1/O Routines of the IOCS moni- 
tor handle the device- specific hardware/ software 
interface. They service I/O device interrupts, 
control the transfer of data to and from the phys- 
ical I/O devices, and initiate new I/O actions 
when appropriate. They also detect hardware 
errors and report them to executing object pro- 
grams and in some cases, perform corrective 
The Physical 


I/O Routines include Device Driver Routines and 


actions to clear error conditions. 


Device Service Routines. 


There is a Device Driver Routine and a 
Device Service Routine for each type of device in 
the standard PTS-100 equipment configuration. 
The Device Driver is called when an I/O request 
has been queued in the logical Input/Output Con- 
trol Queue (IOCQ) table and the channel is in- 


active. The Driver uses the information in the 
appropriate entry of the LOCQ to set up the 
Physical I/O Control table and initiate the re- 
quested I/O action. It calls the Driver Common 
routine to perform any required device- 


independent processing. 


At system generation time, a Device Service 
routine is generated for each device assigned to 
a given external interrupt level. These routines 
identify the cause of an interrupt, update control 
and status fields in the IOCQ entry, take any re- 
quired actions, and then initiate action on the 
next I/O request that is queued as an entry in the 


IOCQ table (see subsection 2.3.1). 


The level service routine for a givenexternal 
interrupt level activates the appropriate Device 
Service routine each time an interrupt is queued 
for its associated device. When several devices 
are assigned to one interrupt level, there is a 
Device Service routine for each assigned device. 
The relative priority of several DSRs on the same 
interrupt level is specified at system generation 
time. The Device Service routines run with 
interrupts enabled, so that an interrupt of a 
higher level can always interrupt processing of a 


lower priority interrupt without delay. 


2.3 IOCS Systems Records 


There are five kinds of systems records used 


by the IOCS monitor: 


e I/O request records, which include: 


Programer defined File Input/Output 
Block (FIOB), which has been assembled 


into the executing program 


Program defined Input/Output Control 
Queue (IOCQ) table entry, used by 
IOCS to queue I/O requests 


IOCS generated Physical Input/Output 
Table (PIOT) 


Two physical control records: 
Input/Output Control Table (IOCT) 
Interrupt Packets 


® Two optional special function records, the 
Search and Translate Tables, defined by the 
programer within the program to be assem- 


bled and executed 
e Monitor Service Call Vector Table 


e Logging tables 


The content and usage of each of these records 


are described in the following subsections. 


2.3.1 I/O Request Records 


There are three kinds of I/O request 
records: the FIOB (File I/O Block), the IOCQ 
(Input/Output Control Queue) table entry, and 


The FIOB contains the programer defined 
That is, the 


programer defines the FIOB in the source pro- 


information on the I/O request. 


gram. At program execution time, the FIOB 
information is passed to LIOCS when the executing 
program issues an IO ACTion service request. 
The IOCS extracts the information from the FIOB 
and enters it into the next entry of the lIOCQ 


table. When the time comes for the hardware to 


perform the requested I/O operation, IOCS 


moves the information from the IOCQ entry into 
the PIOT, where the Physical I/O routines and > 


hardware devices can access and use it. 


While the main data flow is from the execut- 
ing program to IOCS and then to the hardware, 
there is some status information that the hard- 


ware transmits to [OCS for the executing program. 


For example, when the requested I/O operation 


is completed, the hardware reports the logical 
and physical status to IOCS, which makes it 
available to the program via the IOCQ entry. The 


logical status informs the executing program that 


the PIOT (Physical I/O Table). The relationship 


of the required I/O request records for one 


the requested service has been completed, and 


the physical status indicates the type of comple- 


logical unit is shown in figure 1-2. tion that occurred. 


Executing Program IOCS Nucleus IOCS Physical I/O Routines 
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Figure 1-2. Relationship of 1/O Request Records 


For each IO ACTion service to be requested 
from IOCS, the executing program must contain 
a 9-word FIOB describing the parameters of the 
request. For each I/O device channel to be used 
by the executing program, the assembly language 
programer must set up a 10-word IOCQ table 
entry to be placed in the IOCQ table when the I/O 
The first word of the 
IOCQ entry (Word 0) contains the address ofthe 
next IOCQ entry, which is specified by the pro- 


request is queued by 1OCS. 


gram. The second word (Word 1) is used by the 
hardware to report the status of the request to 
the program. The remaining words are filled by 
IOCS from Words 1 through 8 of the FIOB when 
the request is queued. The format and usage of 
the FIOB and IOCQ entry are illustrated in figure 
1-3. See Part 2 of this handbook for detailed 
descriptions of the content of the FIOB and IOCQ 


entry. 


When the executing program issues an 


IOACT request, the FIOB information is accessed |_ 


by the lOCS monitor, which extracts the I/O re- 
quest information in words 1-8 and enters it into 
the next entry of the IOCQ table. When the 
queued 1/O request is to be serviced, the Physi- 
cal I/O Routines of the monitor extract the IOCQ 
entry information and place it in the Physical 
I/O Table (PIOT) for use of the hardware device 
controller that performs the requested I/O 
operation. When the I/O request has been ser- 
viced, the device service routine returns the 
logical and physical status to Word 1 of the 
IOCQ entry. 


The format of the PIOT is shown in figure 
1-4. Notice that the MODE and FUNCtion infor- 
mation occupies the first half of Word 0 of the 
PIOT, and the last half of the word contains an 
8-bit Interrupt Mask. This mask is set up by 


the device driver routine for the associated 
device. Each bit of the mask corresponds with 
a bit in the Interrupt Condition Byte (ICB) in the 
When the 


device controller detects an ICB bit setting, 


hardware controller for the device. 


indicating an interrupt condition, it compares the 


FIOB FORMAT 
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Figure 1-4, Format of the PIOT Generated by 1OCS 


# ISYSF - LUNO 
# ISYSI - LUN 1 
# ISYSL - LUN 2 


# ISYSD - LUN3 
7 ISYSB - LUN 4 
4 ISYST - LUN 5 


bit with the corresponding bit in the Interrupt 


Mask to determine whether the interrupt should 


be "allowed" (i.e., generated). If an interrupt 


is generated, the appropriate LSR receives con- 


LOGICAL- | 
trol, calls the Device Service routine for the TO-PHYSICAL 1-WORD 
POINTERS ENTRIES 


FF ISYSO - LUN 6 
FF ISYSR - LUN 7 
#£ ILOGB - LUN 8 


interrupt level, and the interrupt processing is 


performed. If the interrupt is not "allowed, "' 


FF ILOG9 - LUN 


+e ILOGA - LUNA 
H#- ILOGB - LUNB 
Ie ILOGC - LUNC 


then an invalid interrupt is logged. 


IOCS queueing of I/O requests allows the 
executing program to operate asynchronously | 
with I1/O data transfer operations. The number 
of entries in a particular IOCQ table is defined 
by the assembly language programer when the 


source program is coded. 


2.3.2 Physical Control Records PHYSICAL 7~WORD 
CONTROL ENTRIES 
ae BLOCKS 
The IOCS monitor uses two physical records (PCE) 


to control I/O devices and the interrupt system. 
These records are the I/O Control Table and the 
interrupt packets, both of which are described on 


the following pages. 


2.3.2.1 I/O Control Table. The 1/0 Control 


Table (IOCT) consists of two parts: the logical- 
to- physical device pointers and the Physical 
Control Blocks (PCBs), as illustrated in figure 
1-5. The 1OCT is constructed from System 
Generator macro calls according to user- 


specified physical device assignment on directive 


cards input to the SYSGEN program, described Figure 1-5. Format of the Input/Output Control 
in Part 3 of this handbook, | Table (OCT) 

The logical-to- physical pointers portion of The names of the system-reserved logical units 
the LOCT contains 13 one-word entries containing begin with the characters #ISYS, followed by an 
the identifier of the physical unit assigned to the additional character that denotes the use of the 


logical unit. That is 13 logicalunits maybeassigned unit by system programs. The names of logical 


to actual physical devices. Eight logical units units that may be assigned for applications pro- 
may be assigned for the use of system programs grams begins with the characters #1LOG. The 
(e.g., the Assembler, the loaders, Batch Debug, logical-to- physical pointer entries in the oct 
Dump programs, etc.). Five logical units may and the assigned usage of the units are shown 
be assigned for use of applications programs. in table 1-1. 


Table 1-1. 


LOGICAL UNIT NAME 
HIS YSE (System File) 
#ISYSI (System Input) 
#ISYSL (System Log) 


#ISYSD (System Data) 
#ISYSB (System Binary) 
#iSYST (System List) 
#ISYSO (System Output) 
#ISYSR yaa Scratch) 
#1LOG8 (Logical Unit 8) 
#1LOG9 (Logical Unit 9) 
#LLOGA (Logical Unit A) 
|#ILOGB (Logical Unit B) 


#ILOGC (Logical Unit C) 


Logical-to- Physical Pointer Entries in the IOCT 


PHYSICAL DEVICE 
(D,)* LUN ID 


- LUN 0 
LUN 1 
LUN 2 


LUN 3 


USAGE 
Reading and writing systems program files. 


Reading directive inputs to systems programs 


Writing messages from systems programs. 


Reading data input to systems programs for 


processing. 


Reading relocatable or absolute binary inputs 


to systems programs. 


Writing tabular outputs (i.e., listings) of 


systems programs. 


Systems program writing of binary text of 


absolute or relocatable programs. 


Systems program temporary storage of work 


files. 


Performing applications program I/O 


operations. 


Performing applications program I/O 


operations. 


Performing applications program I/O 


operations. 


Performing applications program 1/O 


operations. 


Performing applications program 1/O 


operations. 


* 
The Dys are the physical device identifiers specified on the System Generator program directive 
that causes the [OCT to be created. Physical devices are assigned to the logical units in the order in 


which their identifiers appear on the directive. 
on the directive is assigned to LUN 0, etc. 


That is, the first device whose identifier, D,, appears 


The PCB portion of the IOCT contains 7-word 


entries that specify the necessary information to 
control the physical devices whose identifiers, 
interrupt levels, and addresses were assigned on 
the appropriate input directive toSYSGEN. As 
many as 22 devices may be assigned addresses. 
For each device, a PCB entry is generated in the 
IOCT. The format of PCB entries is illustrated 


in figure 1-6. 


a: 4 12 15 
fo xara | Word 0 
R_| __ PCBSTATUS INTERRUPT LEVEL 
| COMMAND Word 1 
CODE __DEVICE ADDRESS 

| DEVICE DRIVER ROUTINE ADDRESS Word 2 
| ADDRESS OF IOCQ ENTRY FOR INTERRUPT BEING Word 3 
| QUEUED 

ADDRESS OF IOCQ ENTRY CURRENTLY BEING PROCESSED Word 4 
| PIOT ADDRESS | Word 5 
: (Spare) Word 6 


Figure 1-6. Format of PCB Entries in the IOCT 


2.3.2.2 Interrupt Packets. For each physical 
device assigned an address at system generation 
time, the external interrupt level to which the 
device is to be assigned must be specified. For 
each interrupt level assigned, a 4-~word interrupt 
packet is created in the IOCS monitor being gen- 
erated. The interrupt packets, described in de- 
tail in Part 2 of this handbook, are used by the 
Level Service Routines to record the old and new 
interrupt information when processing control 


passes from one interrupt level to another. 
2.3.3 Special Function Records 


The PTS-100 hardware device controllers 
perform two special functions: the Translate 
function and the Search function. These functions 
use byte table lookups and use the current char- 
acters passing through the controller to offset 


the byte table base addresses. 


The Translate function enables the I/O hard- 
ware device ccntroller to perform code transla- 
tion on the I/O byte stream as it flows into or | 
out of main memory. The Translate function 
therefore allows the programer to specify input/ 
output code conversion (i.e., to specify that 
input/output data characters are to be converted 


to or from the ASCII code used internally by the 


PTS-100). 


The Search function enables the I/O hard- 
ware device controller to test for particular con- 
trol characters within the I/O byte stream as it 
flows into or out of main memory, and to set 
interrupt conditions when the control characters 
appear. Thus, the Search function allows the 
programer to specify hardware testing for the 
occurrence of control characters, and setting of 
interrupt conditions when the characters appear 


in the I/O data stream. 


To utilize these functions, the programer 
must have defined and assembled the associated 
Search and Translate byte tables containing the 
control and/or conversion codes within the pro- 
gram to be executed. The Search and Translate 
functions are specified in conjunction with the 
IOACT service request by entering a code in the 
MODE field of Word 1 of the FIOB, and specify- 


ing the base address(es) of the associated table(s) 


-in the FIOB. Detailed descriptions of the MODE 


code and the Search and Translate table defini - 


tions are presented in Part 2 of this handbook. 


2.3.4 Master Service Call Vector Table 


The Master Service Call (MSC) Vector table 
contains the starting addresses (i.e., entry 
points) of the individual MSC routines that ser- 


vice I/O requests from the executing programs. 


2.3.5 Logging Tables messages will be output on the System Log 
device. Monitor messages output to the logging 
There are three logging tables within 1OCS: device are enclosed in the special symbols < 


and > to differentiate between monitor output 


® Canned Messages Table (CMT), which is and any messages or printouts from an executing 
used for logging messages on the System object program that may also be using the System 
Log device Log device. 

e Message Locate Table (MLT), which pro- Following are the canued messages from the 
vides IOCS with the starting address of each canned message table: 


message in the canned message table 


: END OF JOB, 00 DATA LOST, nn 
® LUN Conversion Table (LCT), which is used DEV NOT OPER,nn STACK OR HOP,nn 
by IOCS to convert the decimal logical unit NO LUN,nn MOTION, nn 
number into ASCII format. LUN OPEN, nn END OF TAPE,nn 
LUN NOT OPEN, nn WRITE PROTECT,nn 
_ These tables are incorporated in a given user's QUE FULL, nn PARITY,nn 
IOCS monitor if message logging is selected by INVALID INTR,nn DEBUG. nn 
the user. If message logging is selected, READ CHECK, nn 


1: 2-9/10 


a? 


Section 3. 


In addition to the IOCS monitor, the following 
software systems are provided to users of the 
PTS-100: 


® PTS-100 Assembler program, which trans- 
lates source programs written in assembly 


- language to object (executable) programs 


@ Utility programs to load, execute, debug, 


and maintain user programs. 


3.1 Assembler Program 

The PTS-100 Assembler program accepts 
source program coding as input and translates 
it to executable machine language instructions. 
The Assembler program must be used to 
assemble all programs to be executed on the 
PTS-100. There are three versions of the PTS- 
100 Assembler: 


e PTS-100 Native Assembler 
e Raytheon 704 Cross Assembler 
e IBM 360/370 Cross Assembler. 


Assembler program processing is accom- 


plished in five phases: 


Phase 0 determines and sets up for the out- 
put options required for the program to be 
assembled and calls the next processing 


phase. 


Phase 1, the macro processor, is called 
when macro calls in source programs must 
be processed, or when an IOCS monitor is 
to be assembled from the macro calls 


generated by the System Generator program. 


Phase 2 analyzes all source statements and 
performs the preprocessing for program 


assembly proper. 


PTS-100 SOFTWARE SYSTEMS 


Phase 3 optimizes core storage requirements. 


of object (assembled) programs. 


Phase 4 completes the construction of 


executable machine instructions, generates 


any required listing of the assembled pro- 
gram, and produces the final object program 


code, 


Part 2 of this handbook discusses the assembly 
language structure and use and Assembler pro- 


gram processing in detail. 


3.2 Utility Programs 


The PTS-100 utility programs are provided 


to perform such functions as: 


Object program loading 


Interactive debugging of object 


programs 


Generation of specially tailored Input / Output 
Control System (IOCS) monitors 


Dumping of the content of main memory 


storage areas 


Dumping binary files to conventional output 


devices 


Program file creation and maintenance 


General descriptions of the functions performed 


3 3-1 


by the utility programs are presented on the 
following pages. Detailed "how to use" descrip- 
tions of the programs are presented in Part 3 of 


this handbook. 
3.2.1 PTS-100 Loader Programs 
Iwo loader programs are supplied with the 


PTS-100: the Piggyback Loader and the 


Absolute/Relocating Loader. The sole function 


of the Piggyback Loader is to load the Absolute/ 
Relocating Loader. The Piggyback Loader is 
bootstrapped into low memory by depressing the 
IPL button on the user console of the PTS- 100. 
Once loaded, the Piggyback Loader loads the 
Absolute/Relocating Loader into high memory 


and starts its execution. 


The Absolute/Relocating Loader must be 


used to load all grams assembled by the 


PTS-100 Assembler, which develops object 
coding in the format required by the Absolute / 


—_ ~ 


Relocating Loader. The object programs may 
be absolute or relocatable, and may consist of 


one or more segments each, 


The Absolute/Relocating Loader computes | 
effective addresses of object program instruc- 
tions, sets up storage areas, loads literal values 
and address constants, relocates relocatable 
programs, establishes linkages between multiple 
program segments, etc. When its loading proc- 
essing is completed, the Absolute/Relocating 
Loader terminates itself and activates the loaded 
program(s) at the execution address defined in 
the last program loaded, or entered manually 
into the PTS-100. | 


3, 2.2 Interactive Debug Program 


The Interactive Debug Program allows the 
programer to interface actively with it during 


object program checkout to effect the following: 


Addition or subtraction of hexadecimal 


constants 


Single or successive memory location 


dumps 


Searches of memory locations for specific 
full word values, or masked searches on 


values less than 16-bits in length 


Alterations of single memory location 


content to a specific value 


Successive memory location loading with 


specific values 
Breakpoint setting and clearing © 


Transfers of control to specific addresses 


and resumption of program execution 


Transfers of control to specific addresses 


e 
m ar hat 
with the accumula and/or one or both 


index registers set to specific values and 


resumption of program execution 


Continuation of previously issued commands 


to the Interactive Debug program 


Input command editing. 


- Thus the Interactive Debug program provides the 


programer with hands-on control of the execution 
of his program. This capability allows selective 
examination of memory, manipulation of memory 
words by accessing and altering them, selective 
execution of any part or all of the program, 
preparation of active unit tests, minor program , 


patching, etc. 


3.2.3 System Generator Program 


The System Generator (SYSGEN) program 
provides for the generation of a specially tailored 
PTS-100 IOCS monitor to meet unique applications 
processing requirements. That is, for any given 
PTS-100 installation, a specialized IOCS monitor 
can be generated by describing its content to the 
SYSGEN program. The system descriptions are 
supplied on key word directive cards, which are 
input to the SYSGEN program. 


SYSGEN analyzes the directives and gener- 
ates specialized macro calls to the generalized 
IOCS monitor routines required in the described 
monitor. The macro calls are written onto an 
Assembler formated file. The Assembler 
processes the SYSGEN macro call file against 
the System Macro Library file (i.e., the gener- 


alized IOCS monitor macro routines file) to pro- 


duce the specially tailored IOCS monitor the user 
described to SYSGEN. 


3.2.4 Memory Dump Program 


The Memory Dump program is a small, | 
easily relocatable program capable of dumping 
the contents of contiguous locations of main 
memory to any sequential storage device that 
The 
length of dumped records depends on the output 


accepts variable length output records. 


device being used. 


There are two versions of the Dump program: 


Version 1 dumps hard copy hexadecimal 
or ASCII records onto a character 


printing device. 


Version 2 dumps relcadable binary 
records to a magnetic tape cassette or 


paper tape punch device. 


Either version of the program may receive dump 
parameters as input from an ASR keyboard device or 
as arguments of a subprogram assembled within 
the main program whose memory locations are 


to be dumped. 
3.2.5 Peripheral Device Dump Program 


The sole function of the Peripheral Device 
Dump (PDD) program is to produce printed 
listings of binary data files stored in one of the 


following media: 


Cassette magnetic tape files 
Punched paper tape files 
Punched card files. 


The output listings of the PDD program are 
either in ASCII code or hexadecimal notation, 
as specified by the programer via a control 


card input to the program. 


Disc files are dumped by a separate program, 


described in subsection 3.2. 7. 3. 


3.2.6 File Update Program 


The File Update program provides a conven- 
ient, easily used method of creating, maintaining, 
and updating files of both object and source pro- 
grams. Thatis, the File Update program may 
be used to create a master file of object and/or 
source programs and subsequently to maintain 
and update the master file. The specific update 
features that can be accomplished using this 


program are: 


Insertion of one or more programs on the 


master file 


Correction of programs by changing their 
names and/or deleting, replacing, or 


inserting data lines 


Replacing one or more programs on the 


master file 


Deletion of one or more programs on the 


master file 


Creation of a file directory of the current 


master file. 


3.2.7 Disc Support Programs 


Three utility programs are available to 
support the use of disc files with the PTS-100. 


3.2.7.1 Disc Volume Preparation. This 
program initializes a new disc for use in the 


PTS-100 system. 


tion on an old disc to prepare it for reuse. 


It can also erase the informa- 
A 
disc must be preprocessed with the Disc Volume 
Preparation program whether it is to accessed by 


physical or logical input/output. 


3.2.7.2 Disc Allocator. 
be used before any disc file can be written or 

If a disc 
is to be accessed solely by physical input/output 


This program must 
read through the logical input/output. 


(not ulitizing the IOCS monitor), it is not neces- 


sary to use the Disc Allocator program. 


Prior to running the Disc Allocator, the 
disc must have been initialized by means of the 
Disc Volume Preparation program. The Disc 
Allocator then assigns disc space to files, 
| extends the disc area allocated to files, and 
deletes files. The program operates from 
free-form keyword type parameters read from 


the card reader. 


3.2.7.3 Disc Dump. The Disc Dump program 
produces a printed listing of data on allora 
selected portion of the sectors of any disc unit in 
use with the PTS-100. The output is listed on the 
serial printer in either hexadecimal or ASCII nota- 
tion, as specified by the input directives. Dump 
parameters are input from the display or teletype- 


writer keyboard in response to program messages. 


3.2.8 Cassette Utility Program 


The Cassette Utility program provides a 


method of storing on, deleting, ‘copying, position- 


ing, and printing the contents of cassette mag- 
netic tape files. A display keyboard is used for 
input directives. The output can be on any of 
four cassette units, the teletypewriter printer, 
or serial printer. The program can perform 


the following functions: 


Copy all or parts of one cassette tape to 


another. 


Forward or backspace one tape a specified 


number of records. 


Position a cassette tape to a specific record 


located by matching a keyword. 
Rewind a tape to its beginning. 


Print a specified number of records from 


one tape. 


Read cards from the card reader and write 


the information to a tape. 


Print the input directives. . 


PART 2 


PTS-100 ASSEMBLER LANGUAGE PROGRAMMING 


mw NY NY LH 


PART 2 


PTS-100 ASSEMBLER LANGUAGE PROGRAMING 


TABLE OF CONTENTS 


Page 


SECTION 1. INTRODUCTION TO THE PTS-100 ASSEMBLER LANGUAGE 


Dm WwW NH KH 


Machine Instructions 


Machine Instruction Execution Timing 


Word and Data Formats 


SECTION 2. 


ASSEMBLER STATEMENT FORMATS 


Source Statement Coding Form 
Label Field 
Operation Code Field 
Operand Field 


2.4.1 
2.4.2 
2.4.3 
2.4.4 
03/445 


Symbolic Tag Operands 


Literal Operands 
Absolute Address Operands 


Self- Reference Operand 


Expression Operands 


Comments Field 


Sequence Number Field 


SECTION 3. DETAILED DESCRIPTIONS OF 
SOURCE LANGUAGE STATEMENTS 


Executable Statements 


ae ee 


Arithmetic Statements 


ae 
ae ee ee, 


3 


— — — pet 
® e e 


ap eee 
3.1.1.4 
Deke de 
i ae ae 


Add Statement (ADD) 


Add Accumulator to Memory 
Statement (ACM) 


Add Immediate Statement (ADI) 
Add One to Memory Statement (AOM) 
Shift Right One, Arithmetic Statement (SRO) 


Subtract Statement (SUB) 


Branch Statements 


ce ee 
3.1522 


3.1.2. 3 


Branch If Accumulator Minus 
Statement (BRM) 


Branch If Condition Bit Set 
Statement (BCB) 


Jump Statement (JMP) 


Compare Statements 


b6 t6:361 


ore were 


Compare Accumulator Less Than 
Word Statement (CAL) 


Compare For Not Equal Statement (CNE) 


2: ill 


Nw NM NM KY LH 


Nm Nw KY NY KY LO 


NY rN WKY NY KH NW 


3.3.4 


TABLE OF CONTENTS 


List Statement (LIST) 


Page 
3.1.4 Load Statements _ a 2: 3-8 
3.1.4.1 Load Address In Index Register 2 
Statement (LAX2) 2: 3-8 
3.1.4.2 Load Byte Statement (LDB) 2: 3-9 
3.1.4.3 Load Immediate Statement (LDI) | 2: 3-9 
3.1.4.4 Load Index Register 1 Statement (LX1) 2: 3-10 
3.1.4.5 Load Index Register 2 Statement (LXZ) 2: 3-ii 
3.1.4.6 Load Word Statement (LDW) 2: 3-11 
3.1.5 Store Statements 2: 3-12 
34 23-54.1 Store Byte Statement (STB) 2: 3-12 
3.1.5.2 Store Index Register 1 Statement (SX1) 2: 3-12 
3248543 Store Index Register 2 Statement (SX2) . 2: 3-13 
3.1.5.4 Store Word Statement (STW) — 2: 3-13 
5.146 Logical Statements 2: 3-14 
$1265 1 AND Statement (AND) 2: 3-14 
| Seiebs2 Exclusive OR Statement (XOR) 2: 3-14 
Nonexecutable Statements | | 2: 3-15 
35201 Constant Assignment Statements | 2: 3-15 
i ey Ape De | Address Constant Statement (ADC) 2: 3-15 
Ce ee ee Concatenated Integer Constant ys 
Statement (CAT) | | 2: 3-16 
3.22165 Decimal Constant Statement (DEC) 2: 3-17 
3.25 164 Hexadecimal Constant Statement (HEX) 2: 3-17 
3.2.1.5 | Octal Constant Statement (OCT) 2: 3-18 
3.2.1.6 Text Constant Statement (TEXT) 2: 3-18 
3.2.1.7 Text Constant (7-bit)Statement(TEX7) 2: 3-18A 
3.2.2 Symbol Defining Statements — | 2: 3-19 
| 3.2.2.1  Equate Statement (EQU) 2: 3-19 
3.2.2.2 External Definition Statement(EXDEF) 2: 3-19 
3226233 External Reference Statement 
(EXREF) 2: 3-20 
3.2.3 Storage Assignment Statements 2: 3-21 
3.2.3.1 Literal Origin Statement (LTORG) 2: 3-21 
3.2.3.2 Mod Statement (MOD) 2: 3-22 
3.2.3.3 Origin Statement (ORG) | 2: 3-22 
(3.2.3.4 Page 0 Statement (PGO) 2: 3-23. 
3.603% 5° Reserve Statement (RESV) 2: 3-23 
Program Control Statements 2: 3-24 
3.3.1 End Statement (END) 2: 3-24 
3.3.2 Skip Statement (SKIP) 2: 3-25 
3.3.3 Unlist Statement (UNLIST) 2: 3-25 
223525 


3.4 


TABLE OF CONTENTS (cont) 


Input/Output Services 
3.4.1 File Input/Output Block Definition 
3.4.2 Input/Output Control Queue Table Definition 
3.4.3 Special Functions 
3.4.3.1 Search Table Definition 
3.4.3.2 Translate Table Definition 
3.4.4 Monitor Service Calls 
3.4.4.1 Device Initialization Service 
3.4.4.2 Device Open Service 
3.4.4.3 I/O Action Service 


3.4.4.4 Device Close Service 
3.4.4.5 System Exit Service 


3.4.4.6 Watchdog Timer Service 


3.4.4.7 Channel Interface Controller 
(CIC) Service 


3.4.4.8 Device Sensing Service 
3.4.4.9 Reconfiguration Service 
Disc Logical Input/Output 
3536 User File Area 
3.5.1.1 Sequential Files 
3.5.1.2 Random Files 
3.5.2 File Description Macro 
Se Ded Main Processing Macro 
3.5.4 Action Macros 
3.5.4.1 Open Macro 
3.5.4.2 Close Macro 
3.5.4.3 Get Macro 
3.5.4.4 Put Macro 
3.5.4.5 Read Macro 
3.5.4.6 Write Macro 
3.5.4.7 Delete Macro 
3.5.5 Status Macros 
3.5.5.1 Wait Macro 
3.5.5.2 Test Macro 


3.5.6 Error Indicators 


SECTION 4, MACRO ROUTINES | 


Basic Macro Routine Structure 
Calling Macro Routines 

Extended Macro Routine Structure 
4.3.1 Statement Label Insertion 


4.3.2 Conditional Inclusion and Deletion of Macro 
Routine Statements 


4.3.3 Embedded Macro Calls 


NNN NNN NN NNN NNN NNN NN DY LD 


N NN NY NM NY NY NYY NY NK ND WN: 


Nm NH NRK WNW 


6.2 


6.4 
6.5 


6.6 | 


TABLE OF CONTENTS (cont) 
SECTION 5. ASSEMBLER PROGRAM 
Programer Inputs 


Se i541 Assembly Control Card Content 


Assembly Processing 


(5.2.1 Phase 0 Processing 


oe 2 Phase 1 Processing 

oe Ae Phase 2 Processing 

5.2.4 Phase 3. Processing 

54255 Phase 4 Processing 

Assembler Output Listing 

Assembler Limitations and Machine Requirements 
5.4.1 Raytheon 704 Cross Assembler | 
5.4.2 IBM 360/370 Cross Assembler 

5.4.3 PTS-100 Native Assembler 


Disc Assembler 


SECTION 6. PROGRAMING TECHNIQUES 


Shifting Techniques 
Setting Addresses 
Defining Message Content 
Label Definition 

Constant Definitions 


Comparison Bit Setting 


SECTION 7. SYSTEM PROGRAMING CONSIDERATIONS 


Interrupt System 

Interrupt Statements | | 

System Programing of I/O Operations 

feet Performing I/O Operations 
7.3.1.1 I/O Packet | 

igecry Testing Device Operational Status 


INDEX TO PART 2 


2: vi 


NN NY NY DM NY DN NY YN NY N NW LK 


ys) 


NNN DN DN NW 


Ny NY NY NY N ND, 


7-3 
7-4 


LIST OF ILLUSTRATIONS 


Assembler-Generated Machine Instruction Formats 
Sample PTS-100 Coding Form 

Format of File Input/Output Block (FIOB) 

Format of Input/Output Control Queue (IOCQ) Entries 
Search Table Format for 8-Bit Code 

Translate Table Format for 8- Bit Code Conversion 
Sample Macro Routine 


Specialized Macro Routine 


Generalized Macro Routine to Create an FIOB 


Generalized Macro Routine for Device Service Requests 
Flow Overview of Assembly Processing 

Sample Assembler Output Listing 

Interrupt Priority Levels in the PTS-100 

Interrupt Packet Format and Content 


I/O Packet 


LIST OF TABLES 


Machine Instruction Execution Times 
Summary of Executable Assembler Statements 


Summary of Constant, Address, and Sd 
Assignment Assembler Statements 


Summary of Program Control Statements 
Summary of I/O Service Statements 


Device Function Field Settings of Bits 3-7 in Word 1 
of the FIOB 


IOCQ Logical Status Codes 


10CQ Physical Status Codes 


Assembler Option Selection 


File (Device) Assignments for Assembly Processing 


Interrupt Statements 


2: vii/ viii 


PART 2. PTS-100 ASSEMBLER LANGUAGE PROGRAMING 


Section l. 


The programing language of the PTS-100 
System is the Assembler language--a symbolic, 
machine oriented language which is suitable for 
solving any application processing problem. 
Applications programs are coded in symbolic, 
or source, statements which are translated by 
the Assembler into object programs that can be 
loaded and executed on the PTS-100 System. 
Locations within programs can be addressed 
through symbolic names (i.e., tags or labels). 
Data constants can be defined in several different 
ways, either as explicit constants or as literals 


coded directly in the source statements. 


A set of source statements constitutes a 
source program. The assembled program is 
called an object program. The object program 
may be either in absolute or relocatable form 
for execution on the PTS-100 system. The 
object program is output on the specific periph- 
eral device used for loading executable programs 
on the specific machine used for program 
assembly. That is, there are three versions of 
the PTS-100 Assembler: 


IBM 360/370 Cross Assembler 
Raytheon 704 Cross Assembler 
PTS-100 Native Assembler 


Object programs are output in one of the 
following forms, depending on the available 


device: 


Punched cards 
Punched paper tape 


Cassette magnetic tape. 


The input/output devices for the three 
versions of the Assembler are specified in 
Section 5 of this part of the handbook, which 
describes the assembly process in detail. 
Assembler language source statements fall into 


four functional groupings: 


INTRODUCTION TO THE PTS-100 ASSEMBLER LANGUAGE 


Executable statements, which the Assembler 
translates into machine instructions (see 
subsection 1.1) to be executed by the 


computer. 
Nonexecutable statements, which set up 
data values and storage areas for executable 


object program use. 


Program control statements, which control 


Assembler output. 


Input/output service statements, which 
effect peripheral device operations via the 


IOCS monitor of the PTS-100. 


The format of Assembler source statements 
is discussed and illustrated in detail in Section 2 
following. Section 3 presents a detailed descrip- 


tion of each statement and its use. 


The PTS-100 assembly language programer 
is provided with the capability of defining gener- 
alized sets of source statements, called macro 
routines, which can subsequently be specialized 
by the Assembler and inserted into any other 
source program. The definition and use of 
macro routines is described in detail in Section 4 


of this part of the handbook. 
1.1 Machine Instructions 


As mentioned earlier, certain Assembler 
source statements are termed "executable! 
statements. That is, these statements are 
translated by the Assembler into machine 
instructions that can be executed by the central 
processing unit (CPU) of the computer. Machine 
instructions are formated as 16-bit (one word) 
instructions or as 32-bit (two word) instructions. 


One word instructions contain five fields and are 


said to be in short format. Two word instruc- 


tions are composed of six fields and are said to 


be in long format. The assembly language pro- oe | Word displacement 
op code 


gramer may specify the long instruction format vane 


(see Section 2), or the instruction length may be 
left to the discretion of the Assembler, which 
determines whether the long or short format is 
required for the instruction. Thatis, the 
Assembler will optimize execution speeds and thet 


memory storage requirements by using the short 


format whenever possible, as described in 


Section 5 of this part of the handbook. The 0 

machine instruction formats are presented in 

: ae : 16-bit byte displacement value 
figure 2-1 and described in detail in the following _ 


paragraphs. D' 


Long Instruction Format 


As shown in figure 2-1, both the long and 


short machine instructions contain OP, R, E, | 
Figure 2-1. Assembler-Generated 


and I fields. The short format contains a D Machine Instruction Formats 


field, and the long format contains a D! field. 
The significance of these fields is described in 


detail below: 


OP (bits 0 - 4): This 5-bit field contains the operation code, which identifies the specific instruc- 


tion to the central processor unit as shown in table 2-1. 


R (bits 5 - 6): This 2-bit field specifies one of four address components to be used in computing 


the effective address, where: 


0 = zero 
1 = contents of the program counter (PC) 
2 = contents of index register 1 (X1) 
3 = contents of index register 2 (X2) 
E (bit 7): This 1-bit field specifies the instruction length, where: 
0 = 16-bit (short format) 
= 32-bit (long format) 
I (bit 8): This l-bit field specifies direct or indirect addressing, where: 


D (bits 9 - 15): 


i) 
i 


direct addressing 


indirect addressing 


except in the following cases: 


When the R field = 1 (PC relative addressing) and the E field = 0 (short format), 


the I field specifies the sign of the 7-bit word displacement value, where: 
0 = positive sign 
l = negative sign 
NOTE 


Indirect addressing is not available 
when R= land E=0. 


In the Add Immediate and Load Immediate machine instructions the I field is not 
used. That is, the short format machine instructions contain four fields: OP 
(bits 0-4) R (bits 5-6), where: 


0 = accumulator 
1 = program counter 
2 = index register 1 


index register 2 


E (bit 7), and the OPERAND field (bits 8-15), which contains the immediate byte 
value to be loaded or added. The long instructions contain five fields, with the 

first three the same as in the short format, the fourth field (bits 8-15) containing 
zeros, and the fifth field (i.e., the second 16-bit word) containing the immediate 


word operand to be loaded or added. 


The D field of a short machine instruction (E = 0) contains a 7-bit positive word 
displacement value to be used in forming the effective address. For short 


machine instructions the effective address is computed as follows: 


R field I=0 I=] 
0 2D (2D) 
1 (PC) + 2D (PC) - 2D 
2 (X1) + 2D ((X1) + 2D) 
3 (X2) + 2D ((X2) + 2D) 


To explain, the displacement value in the D field is multiplied by 2, and the 
product is added to the value specified by the R field except in the case where 
R= 1andI=1, in which case the product is subtracted from the current location 
of the program counter. The current location of the program counter is the 


next instruction. 


The D field content of two machine instructions are exceptions to the above 
discussion. These instructions are the Add Immediate and Load Immediate 
instructions. In the short format of these instructions, the R field indicates 
the register and the D field contains the immediate value specified in the 


operand field of the source statement. 


D' (bits 16 - 3], i.e., 
the second word of 
the two-word 


instruction): 


The D! field of a long instruction (E = 1) contains a 16-bit byte displacement 
value to be used in forming the effective address. Negative displacement values 
are represented in two's complement form. For long machine instructions, the 


effective address is computed as follows: 


R field — Lz0 I=] 
0 D! (D') 
1 (PC) +D! ((PC) + D') 
2 (X1) +D! ((X1) + D') 
3 (X2) +D! ((X2) + D') 


Notice that in all cases the D' field value is added to the value specified by the 


R field. In the case of a long instruction, the current location of the program 


counter is the instruction following the second word (D' field) of the long 


instruction. 


There are two exceptions to the above discussion: the Add Immediate and Load 


Immediate statements, 


In the long format of these machine instructions the R 


field indicates the register and the D' field contains the immediate value speci- 


fied in the operand field of the source statement. 


1.2 Machine Instruction Execution Timing 


Machine instruction execution timing depends 
upon the length of the instruction, the number of 
processor cycles required to execute the instruc- 
tion, and the time required for an instruction 
fetch. Each processor cycle requires 0.160 
microsecond. All machine instructions require 
0.960 microsecond for an instruction fetch. A 
long machine instruction (E = 1) requires 0.960 
microsecond additional for execution. When an 
instruction specifies indirect addressing, another 
0.960 microsecond is required for its execution. 
Hence, a long machine instruction in which in- 
direct addressing is specified requires an addi- 


tional 1.920 microsecond for execution. 


Table 2-1 presents the total execution 
times for all short format (E= 0) machine 
instructions, including 0. 960 microsecond for 


the instruction fetch. 


1.3 Word and Data Formats 


Internally in the PTS-100, instructions and 
The words 
are composed of two bytes (i.e., 8-bit units). 


Internally, data is stored in standard ASCII cade. 


data are stored in 16-bit word units. 


Provision has been made, however, to accept any 
code up to 8 bits per character. That is, input/ 
output controllers perform a special code 
Translate function to convert input/output data 
to or from the 7-bit ASCII code used by the PTS- 
100. 


conversion, the programer must define Translate 


To utilize the Translate function for data 


tables, as described later in Section 3. 


Another special function, the Search function, 
is performed by the PTS-100 input/output con- 
trollers, This function allows programers to 
test for the occurrence of particular I/O control 
characters and specify interrupt conditions when 
the control characters appear in the data stream. 
See Section 3 for a description of this special 


function, 
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Table 2-1, Machine Instruction Execution Times 


: EXECUTION 
| ASSEMBLY TIME** 
A CHINE | MNEMONIC INSTRUCTION (in micro- 


OP CODE* OP CODE seconds) 


Enable Interrupts 
Disable Interrupts 
Interrupt Return 
Monitor Service Call 


17 CAL Compare Accumulator for Less 
than Memory Word 


*The machine op codes here and throughout this handbook are expressed in decimal notation. 


**These times are for short format instructions using direct addressing. They include one 
instruction fetch (0.960 microsecond). 
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Section 2. 


2.1 Source Statement Coding Form 


All assembler source statements are written 
as 80-column records on the coding form shown 
in figure 2-2. A source statement may comprise 


one to five fields in the following order: 


1. <A label field, which is optional except 
for the EQUate statement. 


2. An operation code field, which is 


required for all source statements. 


3. An operand field, required as 
described for the individual statements 


in Section 3. 


4. An optional comments field, which may 
follow the operand field and continue 
through column 72 to document the 
source statement, or which may begin 
with an asterisk (*) in column 1 of the 
coding form and continue across 


columns 2 through 72. 


5. An optional sequence number field, 
which begins in column 73 and ter- 


minates in column 80. 


If all fields are present in a source state- 
ment, they must appear in the sequential order 
shown in figure 2-2. Except for the label and 
sequence number fields, whose lengths are re- 
stricted as shown in figure 2-2, there is no re- 
striction on statement field lengths. The label, 
operation code, and operand fields are ter- 
minated by a blank (A) character. The content 
and use of individual statement fields are 


described below. 


ASSEMBLER STATEMENT FORMATS 


2.2 Label Field 


The label field is optional for all source 
statements except the EQUate statement 
described in Section 3. If a label is used, its 
first character must be alphabetic and must 
appear in column 1 of the source record. Up 
to five additional alphabetic, numeric, or alpha- 
numeric characters may appear in the label field 
(i,e., the label must not continue beyond column 
6 of the coding form). The label field is ter- 


minated by ablank character. Labels may be 


used as symbolic tags in the operand field to 
identify data locations and values on which opera- 


tions are to be performed. 


2.3 Operation Code Field 


This field specifies the mnemonic operation 
code (op code), which identifies a unique state- 
ment specifying action to be taken by the pro- 
gram, the processor, or the Assembler. The 


op codes are of variable iength. 


In executable statements, op codes may be 
followed optionally by from one to two flags, in 
any order, specifying either indirect, indexed, 
or a combination of indirect and indexed address- 


ing. The flags and their significance are: 


N specifies indirect addressing 


X1 specifies indexed addressing using 
index register 1 


X2 specifies indexed addressing using 
index register 2. 


To specify both indirect and indexed addressing, 
the following combinations of flags are valid: 


N,X1 or N, X2 
X1,N or X2,N 


ae ea | 


Aa aes 


Eearricong PROGRAM NAME ee PTS-i00 CODING FORM |  PAGE___OF. 
RAYTHEON 
PROGRAMER 


ASSEMBLER STATEMENT 


SEQUENCE 


OPERATION OPERAND LIST. “BLANKFIELD'. COMMENTS NUMBER 
9 10 11 1213 14 15 l6Lt7 [18 19 20 21-22 2324 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 5 52 535455 5657 58 59 60 GI 6263 64 65 66 67 68 69 70 71 74 75 7% 77 78 79 80 


THT 
COGAALAMGUEEULCGAAGGEEEREEELEEREAAAAAATGUEEEEELEGAAEOGLEELLLE LTT 


LABEL 
[123.45 67) 


Hint SLR eS ais al HHT 
COHMOHG. NOQGQOHE/ AUAMGUWOUSUGUASUSUOUONAEURIOED TTT 
PULL ITT TTT RESEDBRR 
POC 
PST STE 
PTT TTT TTT TTT TTT TTT 
EDR OEE: CARNES: COUR CRATTEE MERA RR RCRO MORN ORR R REDS R AGRO RR OSRROROOSD BOROONON, 


HERE: AGRE EERE 


1234 5 67 8 9 Oli 12 13 14 (5 16 I7 18 IS D 2 22 23 24 25 26 27 28 29 W 3! 32 3 34 35 36 37 383940 41 42 43 44 45 %& 47 48 4950 51 52 53 5455 56 575859 60 61 62 634 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 


FORM NO RDSO6-COI2 REV(I/73) 


Figure 2-2. Sample PTS-100 Coding Form 


If flags are specified they are separated 
from the op code and each other by commas. If 
a label precedes the operation code field, the op 
code field begins with the first non-blank char- 
acter following the blank character that termi- 
nates the label field. If no label is specified, 
column 1 of the coding form must be blank. The 
vp code field may begin in column 2 or any 
column after column 1. The operation code field 


is terminated by a blank character. 


Each source statement is assigned a 
mnemonic op code that uniquely identifies it and 


the operation it specifies. For purposes of dis- 


cussion in this manual, the Assembler source 


statements may be classified as follows: 


° Executable statements, which result in 
Assembler- generated machine instructions 
to be executed by the CPU. Executable 
statements, summarized in table 2-2, 


specify the following: 


Arithmetic operations 


Branches in program execution 


Table 2-2. 


| STATEMENT OPERATION CODE 
| Mnemonic|Ma chine* 
Arithmetic Statements 


Add AC to Memory 


Add 


Add Immediate 


Add One to Memory 


Shift Right One 


Loading of CPU registers with data 


values in memory storage locations 


Storing contents of CPU registers 


in memory locations 
Comparative tests of data values 


Logical (true/false) testing of data 


values. 


e Nonexecutable statements, summarized in 
table 2-3, which define constant data values 


and storage areas for executable program use. 


® Program control statements, summarized in 
table 2-4, which direct the Assembler to 
perform actions regarding the end of the pro- 


gram and the object program listing. 


® Input/ output service statements, which are 
sets of statements defining tables and para- 
meters for use by the IOCS monitor in ser- 
vicing input/output requests, as summarized 
in table 2-5, 


Summary of Executable Assembler Statements 


SPECIFIED OPERATION 


Add contents of accumulator to memory word 
specified by operand; store results in memory 
word; set CB if no carry generated. 


Add contents of memory location specified by 
operand to accumulator value; store result in 
accumulator; set CB if addition overflow. 


Add immediate operand algebraically with con- 
tents of specified register and store in register. 
Set CB if no carry generated. 


Increment memory word specified as operand 
by one; set CB if no carry. 


Shift the value in the accumulator right one bit 
positionand retain sign bit; right-most bit is lost. 


The machine op codes are given in decimal notation. 


ZiiL25 


Table 2-2. 


Subtract 


| Branch Statements 


Branch if AC Minus 


Branch if CB Set 


Jump (unconditional 
branch) 


| Compare Statements 


Compare AC Less than 
Memory Word 


Compare for Not Equal 


Load Statements 


Load Address in tedee 
Register 2 


Load Byte 

Load Immediate 

Load Index Register 1 
Load Index Register 2 


Load Word 


Logical Statements 


And 


XOR 


Summary of Executable Assembler Statements (cont) 


OPERATION CODE 


| STATEMENT Mnemonte 


SPECIFIED OPERATION 


Subtract the value in the memory location speci- | 
fied by the operand from the contents of the 
accumulator; store results in accumulator; set 
CB if arithmetic overflow. 


Branch if value in accumulator is negative 
number (MSB=1). 


Branch if CB set; otherwise execute next 
sequential instruction. 


Jump (unconditionally branch) to execution 
point specified by operand. 


Compare accumulator value with value of 
memory word specified as operand; if AC 
value less than operand value set CB. 


Compare accumulator value with value of 
memory word specified as operand; set CB if 
values not equal, 


Load address of the memory location 
specified by operand into index register Zz. 


Load byte from memory location specified by 
operand into right-hand side of accumulator and 
clear left-hand side. 


Load immediate operand into specified register, | 


- Load memory word specified by operand into 


index ae 1. 


Load memory word specified by operand into 
index register Ze 


Load memory word specified by operand into 
the accumulator. 


And the value in the accumulator with the mem- 
ory word specified by the cperand and place the 
result in the accumulator. Set CB if result not 
zero, 


Exclusive OR the value in the accumulator with 
the memory word specified by the operand and 
place the result in the accumulator, 


* 
The machine op codes are given in decimal notation. 
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Table 2-2. Summary of Executable Assembler Statements (cont) 


| srarewent — (OERARPNSOPE CODE] | 
| | stavewenr —_fOEBRATENCODE TEMENT SPECIFIED OPERATION 


Store Statements 


Store Byte STB Store the right-hand byte value in the accumu- 
lator in the memory word specified as the 
operand, either as left-hand or right-hand 
portion of word, 


Store Index Register 1 SX1 Store content of index register 1] in memory 
word specified by operand. 


Store Index Register 2 SX2 Store content of index register 2 in memory 
word specified by operand. 


Store Word STW Store content of accumulator in the memory 
word specified by operand. 


* ’ ; 
The machine op codes are given in decimal notation. 


Table 2-3. Summary of Constant, Address, and Storage Assignment Assembler Statements | 


! | MNEMONIC] —— | | ee, 
| STATEMENT |orpcope | SPECIFIED OPERATION 


Address Constant Establish an address constant as specified by the expres - 
Definition sion operand, 


Establish a concatenated integer constant as specified by 
the values used as the operand. The CAT statement is 
not implemented in the native version of the PTS-100 
Assembler. 


|Concatenated Integer 
iConstant Definition 


Convert the decimal expression operand to a binary constant 


| Decimal Integer Constant | 
Definition 


Establish a hexadecimal constant one word long as specified 
by the expression operand, 


Hexadecimal Constant 
Definition 


Establish an octal constant one word long as specified by 
the expression operand, 


Octal Constant Definition 


Establish a variable-length alphanumeric constant as speci- 
fied by the operand in 8-bit code. 


Text (alphanumeric con- 
| stant definition) 


Establish a variable-length alphanumeric constant as 


Text (7-bit alphanumeric 
specified by the operand in 7-bit code. 


constant definition) 


Assign the symbol in the label field to the value specified 


Equate Symbol 
by the operand. 


Create a symbol table entry for the symbol operand and its 
address value to enable another program to reference the 
current program in which the symbol is defined. 


External Definition 


Create a symbol table entry for the symbol operand and its 
address value to enable the current program to be linked to 
the program in which the symbol is defined. 


External Reference 
Definition 


Reserve a biock of sequential storage locations for literal 
data values. 


| Literal Origin Storage 
| Specification 


Allocate the next instruction to the next location that is a 


MOD Storage 
| multiple of n, a power of two value specified as the operand.| 


| Specification 


Table 2-3. Summary of Constant, Address, and Storage Assignment Assembler Statements (cont) 


STATEMENT SPECIFIED OPERATION 


Establish the origin of the object program at the absolute 
address specified by the decimal, hexadecimal, or octal 
| operand (i.e., store the first statement of the object pro- | 
gram at the location specified by the operand). | 


Use the absolute address of the symbolic tag specified 
as operand each time it is referenced (i.e., the sym- 
bol is to be assigned an address relative to page 0), 


Reserve an area of memory for buffers, data areas, etc. 


Reserve anarea of memory for buffers, data areas, etc., 
and set each byte location to value xx, if specified. 


Table 2-4, Summary of Program Control Statements 


a ~ [MNEMONIC a 
STATEMENT — OP CODE | _ SPECIFIED ACTION: 


Terminate source program assembly and establish the 
starting address at the first statement to be executed for 
object program execution if an address is specified 
as an operand 


List | LIST Resume printing the object program listing that was 
suspended by the UNLIST statement 


Unlist UNLIST Suspend the object listing until a LIST statement is pro- 
: cessed or until the end of the program 


Skip SKIP Skip, or space, the object listing the number of spaces 
| specified by the operand. 


Table 2-5. Summary of I/O Service Statements 


STATEMENT FORMS 


Mnemonic 
ele ana | Op Code eee 


INI Tialization Service 
Request 


Initializes all 1/O devices (i.e., stops 
any I/O operations in process and re- 
sets logical status bits to the load | 
condition). 


MSC Transfers control to the IOCS monitor 
and informs it that an I/O service is 
required. 


Issue Monitor Service. 
Call 


Identify I/O Command DEC 2 Informs the monitor that the initialization 
Code | request is to be serviced for all 
devices. 
Specify Return Address ADG Address Specifies the location in the object pro- 
| gram to which the monitor is to return 
control, 


OPEN and CLOSE Device 
Service Request 


The OPEN device service sets up IOCQ 
entries and linkages, and checks the | 
operational status of the specified device. 


The CLOSE device service issuesa STOP 
| I/O, whichimmediatelv causes a physical 
and logical shutdown of the specified device.| 


MSC Transfers control to the IOCS monitor 
and informs it that an I/O service is 
required, | 


Issue Monitor Service 
Call 


DEC 6 Informs the monitor that an OPEN de- 


Identify I/O Command 
Code vice request is to be serviced, 
DEC | 1 | Informs the monitor that a CLOSE de- 


vice function is to be performed. 


| ADC address Specifies the object program location 
to which the monitor is to return control, 


Specify Return Address 


Specify the parameter 
address 


ADC symbolic | Directs the monitor to the object pro- 
tag gram location in which the logical unit : 
number identification (LUN ID) is stored, | 
Establish the LUN ID ymbolicl HEX LUN ID Assigns the desired device's LUN 
tag nD 


For OPEN, specify 
IOCQ table starting 
address 


ADC | IOCQ addrj Establishes the beginning location 
(address of first word) of IOCQ for an 
OPEN device request (i.e., when 
Command Code =6). Note that this 
| statement is not used when a CLOSE 
service is specified. 


RESV,00) 2 Establishes a storage area 2 bytes in 
| length in which the monitor is to store 
| a word indicating an error occurrence 
that prevented the successful com- 
pletion of the OPEN or CLOSE service. 


Reserve an error field 
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Table 2-5. Summary of I/O Service Statements (cont) 
STATEMENT FORMS | 


: Mnemonic 


Input/Output Action (IOACT) 
Service Request | 


EFFECT 


Transfers input and output data between 
’ memory and the specified I/O device, » 


Issue Monitor Service 
Call 


Transfers control to the IOCS monitor 
and informs it that an1/O request is 
to be serviced, 


Identify I/O Command 
Code | 


Informs the monitor that a data transfer 
to or from the specified device is to be 
serviced, o 


Specify Return Address address Specifies the location inthe object pro- 
gram to which the monitor is to return 


control, 


Establish the FIOB 
address 


address Assigns the beginning location (address 
of the first word) of the FIOB (File IO 
Block) that contains the programer- 
defined parameters specifying the pre- 
cise I/O action requested, 


EXIT Service Request Provides a common system exit of the 


program when execution is completed, 


Issue Monitor Service 
Call 


Transfers control to the IOCS monitor 
and informs it that an I/O service is 
required. 


Identify I/O Command 
Code 


Informs the monitor that an EXIT 
request is to be serviced. 


At assembly time, the Assembler interprets Symbolic tag (i.e. , label) 


the mnemonic op code of each source statement Litepal Aste sates 


to determine the type of operation requested, 
and translates the source language statement to meenure acerers 

object code format by translating executable. Self- referencing indicator, * 
statements to machine instruction format, re- Expression formed by combining two or 


solving address computations, reserving storage more of the single-element operands above 


locations, etc., as described in Section 5. with plus (+) and minus (-) signs. 


2-4 Operand Field | The operand of an executable instruction may 
| a be followed by the characters 

The operand field of a source statement , L 

specifies the element or elements to be used in 


performing the operation specified in the op code CO EEO rH The tsar em Die ecenae. Gone aching 


field of the statement. The specified operands Po ptrctrQnnte ie Ve vec Re ated. aa ai eaece ene 


fiat aay peisea deka viven re Oe ee nee ene operand field is terminated by a blank character. 


described in the individual statement discussions The operand fields of the Add Immediate and 
in Section 3. In general, an operand may be any Load Immediate statements are special cases, as 
of the following: _ described in Section 3. 


Detailed discussions of the construction and 
use of each type of operand are presented in the 
following paragraphs. 

2.4.1 Symbolic Tag Operands 

A symbolic tag used as an operand may be 
composed of from one to six characters, the 
first of which must be alphabetic. When a sym- 
bolic tag is used as an operand, it must reference 
memory locations or data values defined else- 
where in the current program or in a program 
referenced by the current program. Thatis, a 
symbolic tag operand must have appeared else- 
where in the current program as one or a com- 


bination of the following: 


Label of a statement in the current program. 


Label (i.e., symbolic tag) of an EQUate 
statement, the operand of which specifies 


the actual value of the symbolic tag. 


Operand in an EXternal REFerence state- 
ment (mnemonic op code EXREF) that | 
specifies that the symbolic tag is defined 
in another program referenced by the 
current program. 

NOTE 


When a symbolic tag appears in 


the operand field of the EXREF 
statement, it may also be usedas 
the operand in any statement in 
the current program where 
symbolic tags are permitted. The 
EXREF definition must precede 
any such use, however. 


If more than one symbolic tag appears in an 
expression in the operand field, all but one of the 
tags must have been assigned absolute addresses 


in EQUate statements. 


The use of symbolic tags as operands is 


illustrated in the following examples. 


Example 1: 
OP CODE OPERAND 
JMP ENDJOB 


This statement specifies that program execution 
is to jump (unconditionally branch) to the current 
location of ENDJOB. 


Example 2: 
OP CODE OPERAND 
ADD TOTAL 


This statement specifies that the value currently 
stored in the memory location associated with the 
symbolic tag operand TOTAL is to be added to 
the value in the accumulator, and the result 
stored in the accumulator. 
2.4.2 Literal Operands 

Literal operands are defined within the 
operand field in which they appear. A literal 
definition is written in one of the following 


formats: 


which defines a hexadecimal 
constant value 


=X'constant value' 


which defines an octal con- 
stant value 


=O'constant value' 


which defines a decimal 
constant value 


=D'constant value' 


which defines a decimal 
constant value by default 
(i.e., if neither of the 
letters X,O, or D follows 
the equal sign and the con- 
stant value is not enclosed 
in quotation marks, the _ 
constant value is assumed 
to be a decimal value). 


=constant value 


The constant value must not be greater than 16 
bits (a full word) in length. Leading zeros in 
literal constant values less than 16 bits in length 
are not required in the Assembler source lan- 
guage. Thatis, the Assembler stores literal 
constant values in 16-bit words, right-justified. 
Following are examples of acceptable literal 


operand definitions. 


Example 1: 
OP CODE OPERAND 
ADD | =X'EFF! 


This statement specifies that the value currently 
in the accumulator is to be added to the hexa- 
decimal constant whose value is FF, and the 


result stored in the accumulator. 


Example 2: 
OP CODE OPERAND 


ADD =O'377'! 


This statement specifies that the octal value of 


377 is to be added to the current value in the 


accumulator. 
Example 3: 
OP CODE OPERAND | 
ADD — =D'10! 


This statement specifies that the decimal value 
of 10 is to be added to the current value in the 


accumulator. 


Example 4: 


OP CODE OPERAND 
SUB =10 


This statement specifies that the decimal (default) 
value of 10 is to be subtracted from the value in 


the accumulator. 


2.4.3 Absolute Address Operands 


Absolute address operands may be defined in 


two ways: 


By identifying a symbolic tag as a reference 
to page 0 (see the Page 0 statement descrip- 
tion in Section 3), and subsequently using the . 


tag as an operand. 


By specifying a decimal, hexadecimal, or 


octal memory address as the operand. 


When absolute addresses are used, either 
symbolically with a PGO statement or directly, 
each absolute address is assembled into the 
operand field of the machine instruction and the 
R bits of the instruction are 00. Following are 


examples of the use of absolute address operands. 


Example l: 
LABEL OP CODE OPERAND 
PGO A 
ONE LDW A 
| PGO B 
TWO LDW B 
PGO ae 
THREE LDW C 


The Page 0 statements specify that data 
values associated with symbolic tags A, B, and 
C are to be assigned absolute addresses relative 
to Page 0. Statement ONE specifies that the | 
value in the absolute address assigned to A is to 


be loaded into the accumulator. Statements TWO 


2: 2-10 


and THREE specify the same thing for the values 
of symbolic tags Band C. In these statements, 
direct addressing is specified and the absolute 
addresses of the respective data values will 
appear in the operand fields of the machine in- 


structions generated by the Assembler. 


Example 2: 

LABEL OP CODE OPERAND 
BR1 JMP X'FO! 
BR2 ae O'377'! | 
BR3 wae D'100! 
BR4 JMP 26 


Statement BR1 specifies an unconditional 
jump (branch) of program control to hexadecimal 
FO. 


location 377. 


Statement BR2 specifies a jump to octal 
Statement BR3 specifies an uncon- 
BR4 
specifies a branch to decimal (by default) location 


26. 


ditional branch to decimal location 100. 


2.4.4 Self-Reference Operand 


The self-referencing indicator (*) may be 


used as an operand, as illustrated below. 


DTAG7 ADC * 
DKEY EQU ** 
JMP 6 
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2.4.5 Expression Operands 

Expression operands are formed by com- 
bining any of the previously described single- 
element operands with plus (+) and minus (-) 
signs. Recall, however, that when two or more 
symbolic tags are used as expression elements, 
all but one of the tags must have been assigned 
absolute addresses in EQUATE statements. 


Examples of expression operands are shown: 


below: 
Example |: 
OP CODE OPERAND 
JMP *+16 


The JMP statement specifies a transfer of pro- 
gram control to a point 8 decimal locations (i.e., 
16 bytes) beyond the current location of the self- 


referencing indicator. 


Example 2: 
OP CODE OPERAND 
LDW TABLE +6 


The LDW statement specifies that the accumu- 
lator is to be loaded with the contents of the 
fourth word of TABLE. That is, the third word 
after the first (beginning) word of Table contains 


the value to be loaded. 


Example 3: 
OP CODE OPERAND 
STW X'LFO!'-2 


The STW statement specifies that the value in 
the accumulator is to be stored in the memory 
location just preceding the hexadecimal location 
1FO. | | 


2.5 Comments Field 


The programer may thoroughly document his 
program by writing descriptive comments follow- 
ing the blank character that terminates the 
operand field and continuing through column 72Z. 
In addition, the programer may specify that an 
entire source record (coding line) is to be treated 
as a comment by writing an asterisk (*) in oe 
column | of the source record, and then writing 
the comment text in any columns from 2 through | 
72 of the coding form. Embedded blanks are 
accepted in the comments field. Comments are 
not processed by the Assembler, but are carried 
on the object listing exactly as they were speci- 


fied in the source statements. 


2.6 Sequence Number Field 


The programer may assign a sequence num- 
ber to each line of source coding of his program. 
If sequence numbers are specified, they must 
appear in columns 73 through 80. The sequence 
number field may contain any combination of 
alphanumeric characters from the PTS- 100 
character set. At assembly time, the programer 
may specify the sequence checking of his pro- 
gram by the As sembler, as described in Section 
5. Ifa sequence number field is blank ina 
source statement, sequence checking for the 


associated record is bypassed by the Assembler. 
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Section 3. 


This section presents detailed descriptions 
of all Assembler source statements that may be 
used in coding applications programs for assem- 
bly and subsequent execution on the PTS-100. 
For purposes of discussion, the source state- 
ments are described in the following four 


functional groups: 


Executable statements 
Non executable statements 
Program control statements 


input/output service statements. 


For each source statement, a format diagram is 
presented to graphically illustrate the statement 
fields that may be used and the permissible con- 
tent of each field. In all cases, the mnemonic 
op code must be specified, as shown in upper 
case letters in the format diagrams. Optional 
fields are indicated by enclosing them in paren- 
theses. When a required statement field permits 
a choice in the form of its contents, the permis- 
sible choices are shown enclosed in brackets in | 
the format diagram. When no choice of field 
content is allowed, the form is shown unenclosed. 
The label, op code, and operand fields must be 


terminated by at least one blank character, in- 


. dicated by the character A in the format diagrams. 


Logical input/output for disc files is covered 


separately at the end of the section (subsection 3. 5). 


In addition to the statements presented in 
this section, the programmer may write macro 
routines to be subsequently specialized and in- 
corporated within his programs as described in 


Section 4. 


Special statements and considerations for 
writing systems programs are presented in 


Section 7 of this part of the manual. 


a ek 


DETAILED DESCRIPTIONS OF SOURCE LANGUAGE STATEMENTS 


3.1 Executable Statements 

Executable statements are those source 
statements the Assembler translates to machine 
instruction format for execution by the CPU. As 
described in Section 1, assembled machine in- 
structions are either short (i.e., one word or 

16 bits in length) or long (i.e., two words or 32 
bits in length). 


Short machine instructions contain 7- bit 


operands which specify either word displacement 
values to be used in computing the effective 
addresses of object code or data values, or the 
assigned absolute addresses of object code or data 
values. Thatis, short instructions provide 
addressing capability for +128 words relative to | 
the current program counter value, or addressing 
of +128 words relative to zero or the value con- 


tained in one of the index registers. 


Long machine instructions contain 16-bit 
operands which specify byte displacement values 
to be used in computing the effective addresses 
of relocatable coding or data values, or the 
actual memory location of object coding or data 
values that have been assigned absolute 


addresses. 


Word boundaries in memory are fixed. 
When a memory word is referenced in one of 
the machine instructions generated for a branch 
statement, the least significant bit (LSB) of the 


effective address must be zero. 


In all other machine instructions that 
reference memory words the least significant 


bit (LSB) of the effective address is ignored. 


When a byte address is referenced ina 
machine instruction, the LSB is used to select 
either the left-hand byte (LSB=0) or the right- 
hand byte (LSB=1). _ 


The CPU provides a hardware condition bit 
(CB) to record status as the result of arithmetic 
computations, comparative testing, and the logi- 
cal AND operation. <A condition bit setting of one 


indicates the following conditions: 


Arithmetic overflow 
No carry 
The logical AND operation result is zero 


True results of comparison tests 


The condition bit testing is specified in the 
conditional branch statement (BRANCH IF CB 
SET). The hardware maintains the current: 
status of the condition bit until another instruc- 


tion is executed that alters, or resets, it. 


The executable statements provided in the 
Assembler language are discussed in functional 


groupings in the following paragraphs. 


3.1.1 Arithmetic Statements 


The source language for the PTS-100 
Assembler provides six statements that perform 


arithmetic computations: 


Add (ADD) 

Add Accumulator to Memory (ACM) 
Add Immediate (ADI) 

Add One to Memory (AOM) 

Shift Right One, Arithmetic (SRO) 
Subtract (SUB) 


These statements, their permissible for- 
mats, and the effects of their use are described 
individually below. | 
ee rae 


Add Statement (ADD). The ADD state~- 


ment specifies that the memory word specified in 


the operand field is to be added to the value cur- 
rently in the accumulator, and the re sult of 

the addition is to be stored in the accumulator. 
The acceptable formats of the ADD source state - 


ment are presented in the following diagram. 


LABEL OP CODE | SEQUENCE | 
FIELD FIELD OPERAND/COMMENTS FIELD | NUMBER FIELD | 


(label) A ADD /,N\A Symbolic tag 
ce Literal 


** 


Expression 


At assembly time, the Assembler generates 
either a short or long machine instruction with a 
machine command code of 10 in the op code field, 
and the displacement of the memory word in the 


operand field. 


At program run time, execution of the ADD 


Absolute address 


(xxxxxxxx) 


(,L) A (Comments) 


COL 
ge: 


machine instruction causes the specified memory 
word to be accessed, its value to be added to the 
value in the accumulator, and the resultant value 
to be stored in the accumulator. If the addition 
operation causes an arithmetic overflow, the 
hardware condition bit is set to one; otherwise, 


the condition bit is reset to zero. 


3.1.1.2 Add Accumulator to Memory Statement operand, and the result is to be stored in memory 
(ACM). This statement specifies that the current word. The ACM source statement format is 


value in the accumulator is to be added to the presented in the following diagram. 


contents of the memory word specified as the 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) AACM ],N \ Al Symbolic tag 
| (xxxxxxxx) 
»x1 Literal 
,xX2 Absolute address (,L) A (Comments) 
x 
Expression 
CoO L COL CoOL 
l 6 | 73 
At assembly time, the Assembler generates e Element 1 specifies the register to be used in 
either a short or long machine instruction with in the Add Immediate operation, where: 


the machine command code 30 in the op code field 
AC = accumulator 
and the displacement of the memory word in the 


operand field. PG 


program counter 


X1 


i 


P . . : 1 
At program run time, execution of the ACM index register 


machine instruction causes the specified memory X2 


it 


index register 2 


word to be accessed, the current value of the 


accumulator to be added to it, and the result of e Element 2 specifies the value to be algebra - 
the addition to be stored in the memory word. . ically added to the specified register. The 
The current value of the accumulator is not immediate value may be absolute (coded in 
modified. If no carry is generated by the addition hexadecimal, decimal, or octal notation) or 
operation, the hardware condition bit is set; may be a symbolic tag whose address becomes 
otherwise, the condition bit is reset to zero. the immediate value. 
3.1.1.3 Add Immediate Statement (ADI). This The operand field may optionally contain the 
statement specifies that a value is to be characters , L following the immediate value to 
combined algebraically with the value ina specify that the long machine instruction format 
specific register, and the resultant value is to be is to be used by the Assembler. The elements 
stored in the register. Thatis, the Add Imme- in the operand field of the source statement are 
diate source statement requires a specially for- separated by commas, as illustrated in the 
mated two-element operand, as follows: following diagram. 
ime 
(label) A ADIA ereEveIue (xxxxxxxx) 

PC, value 

X1, value (,L) A (Comments) 

X2, value 

Gry Coe  « | "36015 
] 6 | ™ 73 


At assembly time, the As sembler generates 
either a long or short machine instruction with 
the command code 5 in the op code field and the 


immediate operand in the operand field. 


At program run time, execution of the short 
form of the ADI machine instruction causes the 
byte operand to be treated as a sign plus 7-bit 
magnitude. The 7-bit field is added to the value 


in the register if the sign is positive (i.e., 0) or | 


subtracted from the register if the sign is neg- 
Note that the 7 bit field is 


unshifted when combined with the register data. 


ative (i.e., l). 


Execution of the long format of the ADI 
machine instruction causes the 16-bit operand 
(i.e., the second word of the machine instruc - 
tion) to be added to the value in the register. 


Negative operands are represented in two's 


LABEL 
FIELD 
(label). A AOM],N\aAl. Symbolic tag 
»Xx1 | 
» x2 Absolute address 
* 
Expression 
CoOL COL 


At assembly time, the Assembler generates 
either a short or long machine instruction with 
the command code 31 in the op code field and the 
effective address of the memory word in the 


operand field. 


At program run time, execution of the AOM 
machine instruction causes the specified memory 
word to be accessed, and its value to be incre- 
mented by one. The hardware condition bit is 


set if no carry was generated by the addition 


complement form in the long instruction. 


If the first element of the ADI source operand 
field specified the accumulator (AC), the hard- 
ware condition bit is set when an arithmetic over- 
flow condition occurs. If another register is 
specified (i.e., PC, Xl, X2) as the first element 
of the operand field, the condition bit is set when 
no carry is generated as a result of the ADI 
instruction execution. Otherwise the condition 


bit is reset to zero. 


3.1.1.4 Add One to Memory Statement (AOM). 


This statement specifies that the contents of the 
memory word specified as the operand is to be 
ineremented by one (in the Least Significant Bit). 
The AOM source statement format is presented 


in the following diagram. 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD [NUMBER FIELD | 


(sex300xxxx) 


(,L) A (Comments) 


COL: 


operation; otherwise the condition bit is reset to 


zero. 


3.1.1.5 Shift Right One, Arithmetic Statement 
(SRO). This statement specifies that the value 


in the accumulator is to be shifted one bit posi- 
tion to the right and the sign bit is to be retained; 
the right-most bit is lost. 


As shown in the following diagram, no 


operand is specified in the SRO source statement. 


The programer may optionally specify a label, 


comments, and sequence number field. 


LABEL | OP CODE SEQUENCE 
OPERAND 
FIELD FIELD | (COMMENTS FIELD _ NUMBER FIELD| _ 


(label) A SRO A (Comments) 
COL COL 
] 6 


At assembly time, a 16-bit word is 
generated for use by the CPU when the SRO 
instruction is executed. At execution time, the 
value currently in the accumulator is shifted 


right one bit position. 


(xxxxxxxx) 


CO L 
73 


3.1.1.6 Subtract Statement (SUB). The sub- 
tract statement specifies that the memory word 
specified in the operand field is to be subtracted 
from the contents of the accumulator, and the 


difference is to be stored in the accumulator. 


The Subtract statement format diagram follows. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD JNUMBER FIELD 


(label) A SUB[,N\ A} Symbolic tag 
(xxxxxxxx) 
a Literal 
,X2 Absolute address >} (,L) A (Comments) 
* 
Expression 
COL Co L Co L 
l 6 73 


At assembly time, the Assembler generates 


either a short or long machine instruction with 


the command code 14 in the op code field and the. 


displacement of the memory word in the operand 
field. 


At program run time, execution of the Sub- 
tract instruction causes the specified memory 
word to be accessed, its value to be subtracted 
from the value in the accumulator, and the re- 
sultant difference stored in the accumulator. If 
the subtraction operation causes an arithmetic 
overflow condition, the hardware condition bit is 


set to one; otherwise it is reset to zero. 


3.1.2 Branch Statements 


The source language for the PTS-100 
Assembler provides two conditional and one 
unconditional branch statements to effect trans - 
fers of control within the executable program, 
as follows: | 


Branch if Accumulator Minus (BRM) 
Branch if Condition Bit Set (BCB) 
Jump (JMP) 


These statements, their permissible 
formats, and the effects of their use are de- 


scribed individually below. 


3.1.2.1 Branch If Accumulator Minus State - 
ment (BRM). This statement specifies that the 
program execution is to branch to the location 


specified by the operand if the value in the ac- 


cumulator is a negative number (i.e., if the 
Most Significant Bit = 1). The BRM source 


statement format is presented below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD | NUMBER FIELD 


(label) 


2 BRM/,N\a| Symbolic tag 
,»X1 
»X2 Absolute address 
2 
Expression 
Col; COL 
] 6 


At assembly time, the Assembler generates 
either a long or short machine instruction with 
the command code 3 in the op code field and the 
displacement of the address to which control is 


to branch in the operand field. 


At execution time, the most significant 
bit (MSB) in the accumulator value is tested. If 
it is 1 (minus), the branch address is placed in 
the program counter and the transfer of control 
takes place. If the MSB is 0 (positive) the next 


sequential program instruction is executed. 


LABEL OP CODE oe 
Siete, 


(label) ABCB;,N \A{ Symbolic tag 
a! 
»X2 Absolute address 
* 
Expression 
COL aa 
] 6 


(xxxxxxxx) 


(,L) A (Comments) 


3.1.2.2 Branch If Condition Bit Set Statement 
(BCB). This statement tests the hardware 
condition bit (CB) after the execution ofa 
machine instruction that may have set the CB to 


indicate one of the following: 


Arithmetic overflow 
No carry generated 
The logical AND operation result is zero 


True results of comparison tests 


The BCB source statement format is pre- 


sented below. 


SEQUENCE 
NUMBER FIELD 


(xxxxxxxx) 


(,L) A (Comments ) 


COL 
73 


At assembly time, the Assembler generates 
either a short or long machine instruction with 
the command code 2 in the op code field and the 
effective address to which control is to transfer 


in the operand field. 


When the BCB instruction is executed, the 


condition bit is tested to determine whether it is 


equal to one. If so, the branch address is placed 
in the program counter, and the transfer of con- 
trol takes place. If the CB is not set, the next 


sequential program instruction is executed. 


3.1.2.3 Jump Statement (JMP). This state - 


ment specifies an unconditional branch in program 
execution. The Jump statement format is 


diagramed below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
(label) A JMP/,N \A Symbolic tag (pies 
»,Xl1 
,X2 Absolute address )(,1L) A (Comments) 
* 
Expression 
CoOL COL CoOL 
6 73 


At assembly time, the Assembler generates 
either a short or long instruction with the 
- command code 0 in the op code field and the 
effective address to which control is to transfer 


in the operand field. 


When the Jump machine instruction is exec- 
uted, the branch address is placed in the program 
counter and execution control jumps to the 
specified point. 

3.1.3 Compare Statements 
The PTS-100 Assembler source language 


provides two statements to specify comparative 


testing of the current value of the accumulator 


LABEL 


W ord Statement (CAL). 


against the value of memory words, as follows: 


e Compare for Accumulator Less than 
Memory Word (CAL) 


e Compare for Not Equal (CNE) 


These statements are discussed in detail in the 


following paragraphs. 


3.1.3.1 Compare Accumulator Less Than 

This statement specifies 
comparative testing of the current value in the 
accumulator with the value of the memory word 
specified by the operand to determine whether 

the magnitude of the accumulator value is less 
The CAL state - 


ment format is diagramed below. 


than that of the operand value. 


SEQUENCE 


| OP CODE |. | 
FIELD FIELD JOPERAND/COMMENTS. FIELD. NUMBER FIELD} 
(label) A CAL;,N \A) Symbolic tag (sae 
,X1 Literal | | 
AN, X2 Absolute address PVT) WAGotements ) 

* 

Expression 

COL COL COL 
1 6 73 


At as sembly time, the Assembler generates 
either a long or short machine instruction with 
the command code 17 in the op code field and the 
displacement of the memory word value in the 


operand field. 


At execution time, the value currently 
stored in the accumulator is compared with the 
specified memory word value. If the magnitude 


of the accumulator value is less than the magni- 


tude of the memory word, the hardware condi- 


tion bit is set to one; otherwise the CB is reset. 


3.1.3.2 Compare For Not Equal Statement 
(CNE). This statement specifies that a ''not 


equal! comparison is to be made with the current 
value of the accumulator and the value of the 
memory word specified by the operand. The 


format of-the CNE statement is diagramed below. 


SEQUENCE 


LABEL OP CODE | 
OPERAND/COMMEN ELD 
FIELD FIELD - IC tore NUMBER FIELD] 


(label) A CNE /,N \afl Symbolic tag ; 
(xxxxxxxx) 
»,xXx1 Literal . 
»xXx2 Absolute address })(,L) A (Comments) 
‘i | 
Expression 
CoOL COL COL 
1 6 73 


At assembly time, the Assembler generates 
either a short or long machine instruction with 
the command code 16 in the op code field and the 
displacement value of the memory word in the 


operand field. 


At execution time, the specified memory 
word is accessed and compared with the value 
stored in the accumulator. ‘If the two values are 
not equal, the hardware condition bit is set to 


one; otherwise it is reset. 


3.1.4 Load Statements 


There are six source statements that provide 
assembly language programmers with the facility 
for loading data values or addresses into special 


registers: 


Load Address in Index Register 2 
Load Byte 

Load Immediate 

Load Index Register 1 

Load Index Register 2 


Load Word 
These statements, their permissible formats, 


and the effects of their use are discussed in 


detail on the following pages. 


3.1.4.1 Load Address In Index Register 2 


Statement (LAX2). This statement specifies 


that the address of the operand is to be placed 
in index register 2. The LAX2 statement format 


is diagramed below. 


LABEL 
FIELD 


(label) \ LAX2/,N \j 
,X1 


» X2 


* 


Expression 


At assembly time, the Assembler generates © 
a long or short machine instruction with the 
command code 8 in the op code field and the dis - 


placement value in the operand field. 


At execution time, the actual address of the 
operand is computed and loaded into index 


register 2. 


LABEL 
FIELD 


(label) A LDB 


Literal 


Absolute addres s 


* 


Expression 


At assembly time, the Assembler generates 
either a short or long machine instruction with 
the command code 19 in the op code field and the 
displacement of the byte value in the operand field 
field. 


At execution time, the byte value stored at 
the effective address is loaded into the right-hand 
portion of the accumulator and the left-hand 


portion is zeroed. 


3.1.4.3 Load Immediate Statement (LDI). 
This statement specifies that the value 


specified as the second operand is to be loaded 


Symbolic tag 


Absolute address 


Symbolic tag 


OP CODE , SEQUENCE 
OPERAND 
FIELD /COMMENTS FIELD NUMBER FIELD 


(xxxxxxxx) 


(,L.) A (Comments) 


COL 
73 


3.1.4.2 Load Byte Statement (LDB). This 


statement specifies that a data value one byte 

(8 bits) in length is to be retrieved from the 
memory location specified by the operand, 
stored in the right-hand half of the accumulator, 
and that the left-hand half of the accumulator is 
to be cleared. The LDB source statement 


format is diagramed below. 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(xxxxxxxx) 


(,L) A (Comments) 


CO L 
73 


into the register specified as the first operand. 
That is, the LDI source statement requires a 
specially formated two-element operand, as 


follows: 


Element 1 specifies the register into which 


the numeric value is to be loaded. 


Element 2 specifies the value to be loaded 
into the register specified as the first 
operand. The immediate value may be 
absolute (coded in hexadecimal, octal, or 
decimal notation) or may be a symbolic tag 


whose address becomes the immediate value. 


The operand field may optionally contain 
the characters ,L following the immediate value 
to specify that the long machine instruction 


format is to be used BY the Assembler. The 


elements in the operand field of the LDI source 


statement are separated by commas, as: illustra - 


ted in the following raat aes 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND (COMMENTS FIELD NUMBER FIELD 


(label) A LDI AC, value 
PC, value 
X1l,value 
X2, value 
COL COL 
] £0 


At assembly time, the Assembler generates 
either a long or short machine instruction with 
the command code 4 inthe opcode field. Ifa short 
instruction is generated, the immediate operand 
value appears inthe operand field of the instruction. 
In a longinstruction, the immediate operand value 


appears in the second word of the instruction. 


At program run time, execution of the short 
form of the LDI instruction causes the byte 


operand to be placed in the right half of the 


(xxxxxxxx) 


(,L) A (Comments) 


CO L 
(3 


specified register and the left half to be zeroed. 
Execution of the long form of the LDI instruc - 
tion causes the word operand to be placed in the 


specified register. 


3.1.4.4 Load Index Register 1 Statement (LX1). 


This statement specifies that the value of the 
operand is to be loaded into index register 1. 
The format of the LX1 statement is diagramed 


below. 


LABEL |. OP CODE | : SEQUENCE 
FIELD FIELD |OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A LX1,,N Symbolic tag 
(xxxxxxxx) 
»Xx1) Literal 
,X2 Absolute address (,L) A (Comments ) 
* 
Expression 
COL COL CO L 
] 6 73 


At assembly time, the Assembler generates 
a long or short machine instruction with the 
command code 20 in the op code field and the 


displacement of the memory word to be loaded 


in the operand field. 


At execution time, the specified value is 


loaded into index register 1. 


2: 3-10 


3.1.4.5 Load Index Register 2 Statement (LX2). 


This statement specifies that the value of the 


operand is to be loaded into index register 2. 


The format of the LX2 is presented below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A LX2 7, 


Symbolic tag 


(xxxxxxxx) 
»x1 Literal 
» X2 Absolute address (,L) 4 (Comments) 
* 
Expression 
CoO L a A 


At assembly time, the Assembler generates loaded into index register 2. 


a long or short machine instruction with the 


command code 21 in the op code field and the 3:4,4,6 aiead Word Statement (EDW):. This 


te Picea ener he me ory wore o.be toaaed statement specifies that the value of the operand 


in the operand field. is to be loaded into the accumulator. The format 


At execution time, the specified value is of the LDW statement is diagramed below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A LDW,, Symbolic tag 
(xxxxxxxx) 
»X1 Literal 
»X2/ { Absolute address )(,L) A (Comments) 
*K 
Expression 
COL COL COL 
1 6 73 


At assembly time, the Assembler generates 
either a short or long instruction with the 
command code 18 in the op code field and the 


displacement of the value to be loaded in the 


operand field. 


At execution time, the specified value is 


loaded into the accumulator. 


2: 3-11 


3.1.5 Store Statements 


There are four source statements that pro- 
vide assembly language programers with the 
facility for storing data values or addresses in 
memory locations: 

Store Byte 


Store Index Register 1 
Store Index Register 2 


These statements, their permissible for - 
mats, and the effects of their use are discussed 


in detail on the following pages. 


3.1.5.1 Store Byte Statement (STB). This 
statement specifies that the right-hand byte of 


the data value in the accumulator is to be stored 
in the byte location of the memory word specified 


by the operand. The format of the Store Byte 


Store Word statement is diagramed below. 
LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
(label) ASTB Symbolic tag Gees 
ee 
x2 Absolute address 7 (,1L) A (Comments) 
é | 
Expression 
COL COL Co L 
1 6 73 


At assembly time, the Assembler generates 
either a short or long machine instruction with 
the command code 28 in the op code field and the 
displacement of the value to be stored in the 
operand field. The least significant bit of the 
effective address indicates whether the byte value 
is to appear in the left-hand portion of the memory 
word (i.e., LSB = 
(LSB = 1). 


0) or the right-hand portion 


At execution time, the right-hand byte of 
the accumulator is stored in that portion of the. 
memory word specified by the effective address 


of the machine instruction. 


3.1.5.2 Store Index Register 1 Statement (SX1). 


This statement specifies that the current value in 
index register 1 is to be stored at the memory 
location specified by the operand. The format 


of the statement is presented below. 


LABEL OP CODE SEQUENCE 
FIELD PIeED. OP eeeNDiCOMMENTS 2120 NUMBER FIELD 
(label) ASX] Symbolic tag fie sees en 
ons 
»X2 Absolute address ~(,L) A (Comments) 
* 
Expression 
CoOL CoOL co L 
] 6 73 


2: 3-12 


At assembly time, the Assembler generates 
a long or short machine instruction with the | 
command code 26 in the op code field and the 
displacement at which the value is to be stored 


in the operand field. 


When the SX1 instruction is executed, the 


value in index register 1 is stored in the memory 


location specified by the effective address. 


3.1.5.3 Store Index Register 2 Statement (5X2). 


This statement specifies that the current value in 
index register 2 is to be stored at the memory 
location specified by the operand. The per- 
missible format of the statement is presented 


below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
(label) ASX2 Symbolic tag ee 
ms 
pee Absolute address (,L) 4 (Comments) 
* 
Expression 
COL COL COL 
] 6 73 


At assembly time, the Assembler generates 
either a long or short machine instruction with 
the command code 27 in the op code field and the 
displacement at which the value is to be stored 


in the operand field. 


At execution time, the current value of 


index register 2 is stored in the specified 


memory location. 


3.1.5.4 Store Word Statement (STW). This 
statement specifies that the current value in 
the accumulator is to be stored in the memory 
The Store 


Word source statement format is presented 


word specified in the operand field. 


below. 


LABEL | OP CODE : SEQUENCE 
FIELD Rib One aN COMMENTS EEE 3 NUMBER FIELD 


(label) ASTW Symbolic tag 
Absolute address 
* 
Expression 
COL CoOL 
l 6 


At assembly time, the Assembler generates 
a long or short machine instruction with the 
command code 24 in the op code field and the 


displacement at which the current value of the 


(xxxxxxxx) 


(,L) A (Comments) 


accumulator is to be stored in the operand field. 


At execution time, the current value of the 
accumulator is transferred to the effective 


address. 


3.1.6 Logical Statements 


The PTS-100 Assembler provides the follow-. 
ing two statements for logical combination of 


accumulator and memory word data values: 


AND statement 
Exclusive OR statement 


These statements, their permissible for - 


mets, and the effects of their use are discussed 


in detail on the following pages. 


3.1.6.1 AND Statement (AND). 
specifies that the current value in the accumula- 


tor is to be ANDed with the value specified by the 


This statement 


operand and the result is to be placed in the ac- 
cumulator. The AND source statement format is 


diagramed below. 


LABEL OP CODE SEQUENCE | 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
label AA 
(label) AAND/,N \A] Symbolic tag (ssceeesea) 
»,Xx1 Literal 
»X2 Absolute address 7 (,L) A (Comments) 
* 
Expression 
CoOL COL COL 
] 6 73 


At assembly time, the Assembler generates 
either along or short machine instruction with the 
command code 12 in the opcode field and the dis- 


placement of the memory wordin the operand field. 


At execution time, the bits of the accumulator 


Both bits 


must equal 1 to produce a 11-bit setting inthe re- 


and of the memory word are ANDed. 


sultant value, as illustrated below. 


Current Accumulator Value: 
Memory Word Value: 
ANDed Resultant Value: 


01011101 10010011 
00100000 11101101 
00000000 10000001 


LABEL 
FIELD 
(label) \ XORys,N \A| Symbolic tag 
»X1 Literal 
» x2 Absolute address 
* 
Expression 
COL COL 
] 6 


The resultant value is stored in the accumu- 
lator. If the resultant value of the AND opera- 
tion is not equal to zero, the hardware condition 


bit is set to one; otherwise it is reset. 


3.1.6.2 Exclusive OR Statement (XOR). This 
statement specifies that the current value in the 
accumulator is to be exclusive ORed with the 
value specified by the operand and the result is 
The XOR 


source statement format is diagramed below. 


to be placed in the accumulator. 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD . JINGMBER FIELD 


(xxxxxxxx) 


(,L) A (Comments) 


COL 
73 
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At assembly time, the Assembler generates 
either a long or short machine instruction con- 
taining the command code 11 in the op code field 
and the displacement of the memory word value 


in the operand field. 


At execution time, the bits of the current 
accumulator value and the memory word value 
are XORed to determine the resultant value, 
where one bit but not both must be one to produce 
a 1-bit setting in the resultant value, as illu- 
strated below. 


Current Accumulator Value: 01011101 10010011 


Memory Word Value: 00100000 11101101 


XORed Resultant Value: 01111101 01111110 
The resultant value is stored in the 


accumulator. 
3.2 Nonexecutable Statements 


Nonexecutable statements are those that do 
not result in Assembler -generated machine in- 
structions. Thatis, they are not executed by 
the CPU, but rather establish data values and 
reserve storage areas for use by the executable 
object program. For purposes of discussion, 


these statements are grouped as follows: 


LABEL 


FIELD 
(label) A ADC Symbolic tag 
Absolute address 
* 
Expression 
COL COL 
] 6 


There is one restriction on the use ofa 
symbolic tag in the operand field of the ADC 
statement: if the operand is an external 
reference symbol (i.e., a symbol that is defined 


in a program segment other than the current one 


® Constant assignment statements, which 
are used to establish constant data values 


and address constants. 


e Symbol defining statements, which assign 
values to symbols or identify symbols used 


or referenced by the program segment. 


© Storage area assignment statements, which 
reserve storage areas for literal pools, 
absolute addresses, I/O data buffers and 
the executable program coding. 

3.2.1 Constant Assignment Statements 


Seven types of constants may be definedin 


PTS-100 Assembler source language: 


Address Constants 

Concatenated Integer Constants 
Decimal Constants 

Hexadecimal Constants 

Octal Constant | 

Text (alphanumeric) Constants 
TEX7 (7-bit alphanumeric) Constants 


The constant assignment statement formats 
and usage are described in the following para- 


graphs. 


SwiGaskect 


This statement defines an Address Constant. 


Address Constant Statement (ADC). 


The ADC statement format is diagramed below. 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD NUMBER FIELD] 


(xxxxxxxx) 


A (Comments) 


ob 

73 
as described in the EXREF statement discussion), 
it must be the only element in the operand field. 
That is, it may not appear within an expression 
formed by combining other operand elements 


with the plus (+) or minus (-) sign. 
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3.2.1.2 Concatenated Integer Constant State - 


ment (CAT). This statement is used to construct 
a concatenated integer constant one word (16 bits) 


in length, based on the values specified in the 


operand field. The format of the CAT source 
statement is presented below. However, the 
CAT statement is not implemented in the native 
version of the PTS-100 Assembler. 


LABEL OP CODE SEQUENCE | 
P A 
FIELD FIELD {OPER AND/COMMENTS FIELD NUMBER FIELD 
(label) A CAT expression 
1’ (xxxxxxxx) 
expression, A (comments) where each 
expression is written in the format: 
absolute value:bits 
COL COL ott 
1 6 re 


As shown in the diagram above, the operand 
field may contain one or more expressions, each 


of which is written in the format 
Absolute value:bits 


where the absolute value may be expressed as 


one of the following: 


A symbolic tag previously assigned an 


absolute value via the EQUate statement 
An octal, hexadecimal, or decimal value 
An expression formed by combining any 


of the above with the plus (+) or minus (-) 


sign 


and where bits is a decimal number, from 1 - 16, 


specifying the number of bits the absolute value 
is to’occupy in the 16-bit concatenated word. If 
a string of expressions is specified in the CAT 
statement operand field, the total number of bits 
_ must not be greater than 16. If fewer than 16 
bits is specified for a concatenated word, the 
final value of the word is left-justified, and the 


right-most bit positions are zero filled. 


Following are examples of CAT source 
statements, and the resulting word values 


they produce. 


Example 1: 
CAT X'AB!:8, 12:8 


The expression X'AB':8 specifies that the hexa- 
decimal value AB is to appear in an 8-bit field. 
The expression 12:8 specifies that the decimal 
value 12 is to occupy an 8-bit field in the con- 
catenated word. The resultant integer constant 


constructed by this statement is shown below. 


orgierifoooeiios 


hexadecimal value A B 0 GC: 


binary value 


Example 2 


FIVE EQU 5 
SIX EQU 6 
CAT FIVE-1:3,SIX+4:7, 0'77':6 


The first two statements EQUate absolute values 
to the symbolic tags FIVE and SIX. The CAT 
statement specifies that the value FIVE-1 is to 
appear in.a 3-bit field in the left-most portion of 
the concatenated constant word, the value SIX+4 
is to appear in the next 7 -bit field, and the octal 
value 77 is to appear in the right-most 6-bit 
portion of the word. The resultant integer con- 


stant is shown below. N 


hexadecimal value 8 2 B F 
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3.2.1.3 Decimal Constant Statement (DEC). 


This statement is used to define one or more 


16-bit decimal constants. The format of the 


statement is shown below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPER AND/COMMENTS ee | NUMBER FIELD 
DEC “tnnnnn | 
(label) =A A fan iz ee | ees 
| +nnnnn, tnnnnn,...,+tnnnnn . 
where n's = decimal digits 
COL CoOL COL 
l 6 73 


One or more decimal constant values may 
appear in the operand field. If two or more 
constant values are specified, they must be 
separated by commas. The magnitude of any 
given constant value must be less than 65535. 
Constant values may be preceded by the plus (+) 
or minus (-) signs. If a negative decimal value 
is specified, the two's complement of the binary 
representation of the value appears in the 16-bit 
memory word. The decimal constant value is 
right-justified in the memory word, with the left- 


most unused portion zero-filled. Ifa label 


appears in the label field of a DEC statement in 
which a string of constant values is specified, 

the label will become the symbolic tag of the 

first value in the operand field. Thatis, strings © 
of values are assigned to consecutive storage 
locations, with the tag associated with the first 


(lowest) memory address. 


3.2.1.4 Hexadecimal Constant Statement (HEX). 
This statement is used to define one or more 
16-bit hexadecimal constant values, as shown in 


the following diagram. 


OP CODE | SEQUENCE 
aes OPERAND/COMMENTS FIELD MUABER ec 


LABEL 
FIELD 
(label) \ HEX A eee 
A (Comments) 
where n's = 
hexadecimal digits 
COL COL COL 
l 6 73 


In the HEX statement, one or more hexa- 
decimal constant values may be specified, each 
from one to four-digits in length. If two or more 
constant values are specified, they are separated 
by commas. If a label is specified for a state- 
ment in which a string of values is specified, the 


label becomes the symbolic tag of the first value 


in the operand field. Thatiis, strings of values 
are assigned to consecutive locations, with the 
symbolic tag associated with the first (lowest) 
memory address. If less than four digits are 
specified in a given value, the binary represen- 
tation of the value is right -justified, with the 


left-most unused bit positions zero-filled. 
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3.2.1.5 Octal Constant Statement (OCT). The 


OCT statement is used to define one or more 16- 


bit octal constant values, as shown in the follow- 


ing diagram. 


LABEL OP CODE SEQUENCE 
FIELD ery jo ee eee NUMBER FIELD 
(label) A OCT A nnononn | 
(xxxxxxxx) 
nnnnnn,..., nnnnnn 
A {Comments ) 
where n's = 
octal digits 
COL COL CO I, 
l 6 73 


As shown in the diagram above, one or more 
octal constant values may be specified, each 
from one to six digits in length. Ifa label is 
specified for a statement in which a string of 
values is specified, the label becomes the sym- 
bolic tag of the first value in the operand field. 

If less than six digits are specified in a given 
octal constant value, the binary representation 
of the value is right-justified in the memory 


word, with the left-most unused bit positions 


zero-filled. If six digits are specified, the two 


high-order bits of the first digit are truncated. 


3.2.1.6 Text Constant Statement (TEXT). This 
statement is used to define an alphanumeric 
constant from one to forty characters in length. 
The alphanumeric constant value appears in the 
operand field, as shown in the format diagram 


below. 


SEQUENCE 


LABEL | OP CODE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A TEXT A 


'alphacon' A (comment) 


(xxxxxxxx) 
COL COL COL 
] 6 73 


The alphanumeric constant value must be 
enclosed in single quotation marks, which are 
used as delimiters. The constant value may 
contain any characters from the PTS-100 
character set (see Appendix A) except the single 
quotation marks. If quotation marks are to | 
- appear within the alphanumeric constant value, 
the programer uses double quotation marks, | 
which will be replaced by the single quotation 


marks when the constant value is assembled. 


Alphanumeric constants must start on a word 


boundary. 


Alphanumeric constants are stored as 8-bit 
ASCII characters (i.e., two characters per 
memory word). If the constant value contains an 
uneven number of characters, the last character 
will appear in the left-most byte of the last 
memory word, and the right-most byte will be 
blank -filled. | 
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3.2.1.7 Text Constant (7-bit) Statement (TEX7). The alphanumeric constant value appears in the 
This statement is used to define an alphanumeric operand field, as shown in the format diagram 


constant from one to forty characters in length. below. 


LABEL | OP CODE | SEQUENCE 
ea aia OPERAND/COMMENTS FIELD Fr or eer aren 


(label) A TEX7 A lalphacon!' A (comment) (xxx) 


COL CoOL COL 
1 6 73 

The alphanumeric constant value must be Each character in the alphanumeric constant 
enclosed in single quotation marks, which are is treated as a 7-bit ASCII character and stored 
used as delimiters. The constant value may as an 8-bit character, with the most significant 
contain any characters from the PTS-100 bit (MSB) set to 0 (i.e., two characters per 
character set (see Appendix A) except the single memory word). If the constant value contains an 
quotation mark. If quotation marks are to appear uneven number of characters, the last character 
within the alphanumeric constant value, the will appear in the left-most byte of the last 
programer uses double quotation marks, which memory word, and the right-most byte will be 
will be replaced by the single quotation mark blank-filled. 


when the constant value is assembled. Alpha- 


numeric constants must start on a wordboundary. 
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3.2.2 Symbol Defining Statements 3.2.2.1 Equate Statement (EQU). This state - 


ment is used to assign an absolute address value 


Three source statements are used to define toa symbol. The symbol must appear in the 
or identify symbols in the PTS-100 assembly label field of the source statement, and the 
language: operand field must contain the absolute address 


value, expressed as one of the following: 


@ The Equate statement is used to assign an 


absolute value to a symbol. The self-referencing indicator (**) 
e The External Definition statement informs An absolute decimal, hexadecimal, or 
the Assembler that a defined symbol in one octal number 


program segment is to be referenced in 
another program segment. Another symbol, previously assigned an 


absolute number value in another EQUate 


° The External Reference statement informs statement. 


the Assembler that a referenced symbol in 


one program segment is to be defined in The format of the Equate statement is 
another program segment. presented below. 
LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
(label) A EQU A | Symbolic tag (xxxxxxxx) 
| Absolute number 
ay A (Comments) 
COL COL COL 
] 6 73 
At assembly time, the operand field is 3.2.2.2 External Definition Statement (EXDEF),. 
evaluated and the resulting absolute number is This statement is used to inform the Assembler 
assigned as the address value of the specified that the symbol defined in the immediately pre- 
symbol in the symbol table created by the ceding or following source statement in the pro- 
_ Assembler. gram segment currently being assembled is to 


be referenced in some other program segment 


Each time the symbol is referenced in the to which the current segment will be linked at 
executable program, the address value is used load time. The EXDEF statement format is 
to locate the associated data value. presented below. 
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OP CODE 
FIELD 


A EXDEF 4A 


Note that the label field in the EXDEF state- 


ment is not used. That is, a label specified for 


this statement will be ignored by the Assembler. 


The EXDEF op code may begin in any column 


other than column 1, which must be blank. 


At assembly time, the Assembler places 
the named symbol and its address value in the 
symbol table. The symbol and its address are 
subsequently written on the relocatable loading 


file. At load time, the relocating loader re- 


(EXREF). 


SEQUENCE 
A 
OPERAND/COMMENTS FIELD NUMBER, FIELD 


Symbolic tag A (comments) 


(xxxxxxxx) 


solves the address of the symbol when it is 


referenced in another program segment. 


3.2.2.3 External Reference Statement | 

This statement informs the Assem- 
bler that a symbol referenced in the program 
segment currently being assembled is defined 

in some other program segment to which 

the current segment will be linked at load time. 
The EXREF statement format is diagramed 


below. 


OP CODE eet SEQUENCE 
FIELD one aD EON: ioe be os eB) NUMBER FIELD 


AEXREF a Symbolic tag A(comments) , 
| (xxxxxxxx) 
COL COL CO L 
] 6 73 


Note that the label field in the EXREF state - 


ment is not used. That is, a label specified for 
this statement will be ignored by the Assembler. 
The EXREF op code may begin in any column 


other than column 1, which must be blank. 


At assembly time, the Assembler places 


the symbol in the symbol table. The symbol and 
the addresses referencing it are written on the 
object file for resolution by the Absolute/ 
Relocating Loader. At load time, the address of 
the symbol is resolved by the Loader when the 
current program segment is linked to the 


program segment in which the symbol is defined. 
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3.2.3 Storage Assignment Statements 


The storage assignment statements allow the 
programer to establish memory storage locations 
for source coding, literal values, and buffer or 
data areas. There are five storage assignment 


statements: 


e Literal Origin statement, which establishes 
the storage areas for blocks of literal data 


values, 


® MOD statement, which causes the instruction 
following it to be allocated to the storage 
location that is the next higher multiple of 


a given power of two. 


° Origin statement, which specifies the 
beginning storage location at which object 


program loading is to begin. 


OP CODE 
FIELD 


A LTORG a (comments ) 


As shown above, the label field and the 
operand field are not used in the LTORG state - 
ment. The op code may begin in any column 
after column 1, which must be blank. The op 
code is terminated by a blank character, after 


which a comment may be specified. 


When the Assembler encounters a LTORG 
statement in a source program, it establishes 
a literal storage area, beginning with the loca- 
tion at which the LTORG statement was en- 
countered and continuing through the number of 
sequential locations required to store all literals 


defined since the beginning of the program, or 


® Page 0 statement, which causes an absolute 


addres« to be assigned to a symbol. 
e Reserve statement, which specifies that a 


memory area is to be reserved for use as 


a buffer or data storage area. 


These statements are described in the following 


paragraphs. 
3.2.3.1 Literal Origin Statement (LTORG). It 


is the programer's responsibility to indicate 
where literal data values are to be stored within 
his program. The Literal Origin (LTORQG) 
statement is used to inform the Assembler that 
a literal storage pool is to be set up within the 
program. The LTORG statement format is 


diagramed below. 


SEQUENCE 


JOPERAND/COMMENTS FIELD NUMBER FIELD 


(xxxxxxxx) 


CO L 
73 


since the last LTORG statement was encountered. 
That is, all literal values defined prior to the 
occurrence of a given LTORG statement are 
assigned storage locations in the same sequential 
order as their appearance in the program. 
Duplicate literal values are eliminated only when 
they both appear within the block of source 

coding preceding a given LTORG statement. 
Thus, the Assembler establishes a new literal 
table each time a LTORG statement is encounter - 
ed, and writes the previous literal table on an 
Intermediate Text rae Therefore, redundant 


entries between tables are not eliminated. 


22 522A 


3.2.3.2 Mod Statement (MOD). This statement 
specifies that the statement immediately follow- 


ing it is to be stored in the next storage location 


that is a multiple of the power of two which is 
specified as its operand. The MOD statement 


format is shown in the diagram below. 


OP CODE SEQUENCE 
FIELD | OPERAND/COMMENTS FIELD NUMBER FIELD 
AMOD A decimal number {A (comments) (xxxxxxxx) 
Co L COL CO LL 
6 73 


As shown above, the label field in the MOD 
statement is not used. The op code may begin 
in any column after column 1, which must be 
blank. The op code is terminated by a blank 
character, after which the operand is specified 
as a decimal number, which must be a power of 
two. When the Assembler encounters this state - 
ment, it locates the object coding of the state - 


ment immediately following the MOD statement 


A ORG A 


COL: “GOL 
1 6 
As shown in the diagram above, the ORG 

statement label is optional. The operand field of 
the statement must specify the absolute address, 
which must be expressed as a hexadecimal, octal, 
or decimal number. Ifa label is defined for the 
ORG statement, it is assigned the address value 


of the operand. 


If a program contains several segments, 


only one segment (the one to be loaded first) may 


OP CODE | SEQUENCE 
REL OPERAND/COMMENTS FIELD pea eee 


Absolute address A (comments) 


at the next full-word location that is a multiple. 


of the value specified as the operand. 


3.2.3.3 Origin Statement (ORG). One ORG 


statement may optionally be used as the first 
statement in a source program to specify the 
origin of the object program (i.e., the first. 
memory location at which object program loading 
is to begin). The ORG statement is diagramed 


below. 


(xxxxxxxx) 


contain an ORG statement at its beginning. If 
more than one ORG statement should appear in 
a program, the duplicate statement(s) will not. 
be detected by the Assembler. Thatis, the 
statements will be accepted, and unpredictable 


results will occur at load time. 


If no ORG statement appears in a program, © 


object program loading will begin at location 0. 


22 3<2e 


3.2.3.4 Page 0 Statement (PGO). The PGO 
statement is used to specify that a symbolic tag 


is to be assigned an absolute address when it is 


OP CODE 
FIELD 


A PGO A 


As shown above, the label field is not used 
in the Page 0 statement. The op code may begin 
in any column after column 1, which must be 
blank. The operand field may contain one 
symbolic tag of a data value defined in a state - 
ment immediately following or preceding the 
Page 0 statement. Thatis, the Page 0 source 
statement must physically appear either immed - 


iately before or after the statement in which the 


value of the symbol is defined. The symbol may > 


be defined as the label of an EQUate statement 
whose operand specifies its actual value, the 
label of some other statement in the current 


program, or the operand of an EXREF state - 


used in an executable instruction. The format of 


this statement is shown below. 


SEQUENCE 
PERA 
OPERAND/COMMENTS BrRD2 NUMBER FIELD 


Symbolic tag A (comment) 


(xxxxxxxx) 


ment in the current program. 


The PGO statement identifies the symbolic 
tagasa reference to page 0; thus when the sym- 
bolic tag is used in an executable instruction, 
the absolute address of the symbolic tag appears 
in the operand field of the Assembler -generated 


machine instruction. 


3.2.3.5 Reserve Statement (RESV). This 

statement is used to inform the Assembler that 
an area of memory is to be reserved for use as 
a buffer or a data storage area. It is written in 


the formats shown below. 


LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) 4 RESV A 


absolute naan A (comment) 


(xxxxxxxx) 
RESV ,x* A 
COL COL COL 
6 73 


A label may optionally be specified for the 
Reserve statement. If it is specified, itis 
assigned the address of the first word location 


of the reserved area. 


The op code may be written in either of the 


forms: 


RESV or RESV, xx 
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The first form specifies that a zero-filled | 
storage area of the byte-length specified by the 
operand is to be reserved on a word boundary 
in memory. .The RESV,xx form specifies that | 
every byte location in the reserved area is to 


be set to the hexadecimal value specified by xx. 


The operand of the RESV statement must be 
an absolute number expressed in octal, hexa- 
decimal, or decimal notation, specifying the 
number of bytes to be reserved. If the absolute 
number is an odd number, the Assembler incre - 
ments it by one (i.e., makes it even) to preserve 
subsequent storage allocation on word boundaries. 
Thus, the Assembler responds to the Reserve 
statement request by reserving enough full 
storage words to accommodate the maximum 


number of bytes specified in the operand field. 


3.3 Program Control Statements 


The program control statements allow the 
programer to control the object program listing, 
to specify the end of program assembly, and to 
specify the starting address for program execu- 
tion. There are four such statements in the 


PTS-100 Assembler language. 


e The END statement, which terminates 
program assembly, and optionally specifies 


the starting address for program execution. 


e The SKIP statement, which controls the 
vertical spacing of the object program 
listing. | | 

r The UNLIST statement, which tells the 
Assembler to suspend production of the 
object program listing. | 

® The LIST statement, which rescinds the 
UNLIST siaveievt (i,e., restnies produc- 


tion of the object program listing). 


These statements are individually described 
below. 


3.3.1 End Statement (END) 


The END statement marks the end of the 
source program (i.e., terminates a given assem- 
bly) and may optionally specify the starting 
address of program execution (i.e., the address 
of the first instruction to be executed in object 
program, which is the point at which the 
Absolute/Relocating Loader is to turn control 
over to the executable program). The format of 


the END statement is paeeas below. 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD [NUMBER FIELD 
AEND A Symbolic tag (xxxxxxxx) 

Absolute Address 

7* 

Expression 

COL COL COL 
] 6 73 


As shown above, the label field is not used 
in the END statement. The op code may begin 
in any column after column 1, which must be 
blank. The operand is optional in the END state - 
ment. If present, it may contain any of the ele- 
ments shown above. When several program 


segments are to be individually assembled and 


combined into one object program, only the last 


segment should contain an END card witha 


starting address specified in the operand field. 


That is, when the Loader loads an END state - 
ment with a starting address, it places the 
address'in the program counter and starts execu- 


tion of the program. Hence, when the program 
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is to be debugged, the END statement of the 
source program must not contain an execution 
starting address if the Debug program is to be 
loaded as the last part of the object program to 
be debugged, as described in Part 3 of this 
handbook. 


3.3.2 Skip Statement (SKIP) 


The SKIP statement causes the object listing 
produced by the Assembler to be vertically 
spaced as specified by the operand. The format 


of the statement is shown below. | 


OP CODE SEQUENCE 
| ee OPERAND/COMMENTS FIELD Sarees 


ASKIP A P 


The label field is not used in the SKIP state- 
ment. The op code may begin in any column 
after column 1, which must be blank. The oper- 
and may be a decimal number from 1-10, spe- 
cifying the number of print lines to be skipped 


withina given page of the object listing, or the 


value P, specifying thatthe Assembleris toskipto 
the top of the next page to continue the object listing. 


COMMENTS FIELD 


OP CODE 
FIELD 


AUNLIST A 


As shown above, the label and operand fields 
are unused in the UNLIST statement. The op 
code may begin in any column after column l, 
which must be blank. The object listing remains 
suspended from the point at which an UNLIST 
statement is encountered until a LIST statement 
appears in the program, or until the end of the 


source program. 


(xxxxxxxx) 
decimal number 


COL 
(3 


ae ee 


Unlist Statement (UNLIST) 


The UNLIST statement specifies that the 
Assembler is to temporarily suspend the output 
object listing at the point at which the UNLIST 
statement is encountered. The UNLIST state - 


ment is diagramed below. 


SEQUENCE 
NUMBER FIELD 


(xxxxxxxx) 


CO L 
73 


3.3.4 List Statement (LIST) 


The LIST statement rescinds the UNLIST 
statement. That is, it tells the Assembler to 
resume printing the object program listing. 

Only the op code LIST is required in the state - 
ment, beginning anywhere after column 1, which 


must be blank, as shown below. 
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OP CODE 
FIELD 


A LIST A 


t 


COL CoOL 
] 6 


3.4 Input/Output Services 


With each PTS-100 System an IOCS monitor 


is available to perform the following functions: 
Automatic device interrupt handling 


Processing I/O requests from applications 


programs. 


The device interrupt handling capability is 
built into the specific IOCS monitor for a given 
PTS-100 when the user's system is generated. 
Thus, device interrupt handling is performed 
automatically for individual programs according 
to the parameters and priorities defined prior to 
system generation. For a description of avail- 
able devices, their logical unit number identifi- 

cations (LUN ID's), and the interrupt priorities 
assigned to them, the programer should con- 
sult the system generation documentation of his 
specific PTS-100 System. For description of 
logical IOCS for disc see Section 3.5 of this part. 


Applications programs may request the 
following basic.I1/O device services from the 


monitor: 


Device initialization 
Device opening and closing 
Device input/output actions 


A common system exit at the end ofa 


processing job. 


In all cases, a program must issue a moni- 
tor service call (i.e., a source statement with 


MSC in the op code field) to signal a request for 


| | SEQUENCE 
COMMENTS ere NUMBER FIELD 


(xxxxxxxx) 


monitor services. The MSC statement must be 
followed immediately by a Decimal Constant 
(DEC) statement whose operand is one of the 
following monitor service identification codes: 


0 = request for a common system 
EXIT 


1 = request to CLOSE a specific device 
2 = request to INITialize all devices 
3 = request for Watchdog Timer Service 


4 =-request for channel interface controller 
service 


5 = request for device status sensing 
6 = request to OPEN a specific device 


7 = request to perform a specific I/O file 
action (IOACT) on a specific device 


ll= request to change peripheral device 
addresses 


Except for the EXIT request, the DEC state - 
ment must be followed by an Address Constant 
statement whose operand is an address within 
the program to which the monitor is to return 
processing control when the request has been 


serviced. 


The three service requests concerned with 
specific devices are CLOSE, OPEN, and IOACT. 
The argument lists for these requests must 
specify the device to be used by passing the logi- 
cal unit number identification (LUN ID) to the | 
IOCS monitor. In the CLOSE and OPEN requests, 
the LUN ID is passed to the monitor via a con- 


stant statement. In the case of the IOACT 


2: 3-26 


request, the LUN ID is passed to the monitor in 
a programer -defined table called the file I/O 
Block (FIOB), described in subsection 3.4.1. 
The FIOB is referenced in an Address Constant 
statement which appears as the last argument of 
the IOACT request. Associated with the FIOB is 
the programer -defined Input/Output Control 
Queue (IOCQ) table entry, described in detail in 
subsection 3.4.2. The IOCQ table is used by 
the monitor to queue I/O requests for particular 
input/output device channels. An IOCQ table 
entry is required for each IOACT request. In 
the OPEN request, the starting address of the 
IOCQ is given as an operand in an Address 


Constant statement. 


For CLOSE and OPEN requests, the last 
argument must be a Reserve statement to set 
up a storage word in which the monitor can 
store a code indicating any error that may occur 
during the attempt to OPEN or CLOSE the device. 
In the case of the IOACT request, the device 
error code is returned to the FIOB, as described 


below. 
3.4.1 File Input/Output Block Definition 


For each input/output service requested 
from the IOCS monitor, the programmer describes 
the parameters of the request in a 9-word File 
Input/Output Block (FIOB), the format of which 


is shown in figure 2-3. 


Bits eiitatletetei pele tele Pade eye 
| (spore) | eRRORCODE 


Word 0 

Word 1 LOGICAL UNIT NUMBER ID 
Word 2 BUFFER ADDRESS (starting byte) 

Word 3 BYTE COUNT | 

Word 4 TRANSLATE TABLE BASE OR DISC ADDRESS _ 

Word 5 SEARCH TABLE BASE OR DISC ADDRESS Z 
Word 
Word 7 (Spare) 

Word 8 


(Spare LUN 
. exten- 
| | sion 


Figure 2-3. Format of File Input/Output 
Block (FIOB) 


The individual fields of the FIOB and their 
significance are as follows: 


Word 0: Error Code Field (8-bit field). After 


Word 1: 
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the I/O request has been processed, 
the IOCS monitor returns one of the 


following codes to this field: 


Code , @ueeaning. 
0 No error 
] Device not operational 
2 No such LUN 
3 LUN already open 
4 LUN not open 
5 Queue full 


This word contains three fields: the 
data transfer MODE field, the device 
FUNCTION field, and the LUN ID 


field, as described individually below. 


MODE field (bits 0 - 2): the programer 
specifies the data transfer mode to be 
used by the device controller by setting 


these bits to the appropriate value, as 


follows: 
Value Transfer MODE 

0 No Search or Translate func - 
tion is to be used. 

] | Use the Translate function 
with no interrupt condition 
when the MSB is on, using 
the Translate Table Base 
(TTB) whose address is 
specified in word 4 of the 
FIOB. 

2 Not defined 

3 Not defined 

4 Not defined 


Value Transfer MODE 


5 Use Translate function with . 


interrupt condition when MSB 


is on (i.e., Search and Trans - 


late through a common table 
using the Translate Table 
Base whose address appears 
in word 4 of the FIOB). 


6 Use Search function and set 
interrupt condition when the 
MSB is on. : 
only and use the Search Table 
Base (STB) whose address is 
given in word 5 of the FIOB. 


That is, search 


7 Use Search function and set 
interrupt condition when the 
MSB is on, using the STB, 
then translate with no inter- 
rupt condition when the MSB 
is on, using TTB addressed 
in word 4 of the FIOB. 


FUNCTION Field (bits 3-7): This field 
specifies the code for the particular de - 
vice function requested (i.e., read, 
write, rewind, etc.). The specific 
codes for various device functions are 


shown in table 2-6. 


LUN ID Field (bits 8-15): The pro- 
gramer uses this field to specify the 
assigned LUN ID of the device control- 
ler on which the I/O request is to be 
performed. The IOCS monitor will 
translate the LUN ID into the physical 


address of the requested device. 


Word 2: In this word the programer specifies 


the 16-bit starting address of the buffer 
to or from which input or output data is 


to be transferred. 


Word 3: 


Disc 
Word 3: 


Word 4: 


Disc 
Word 4: 


Word 5:3 


Disc 
Word 5: 


Word 6: 
Word 7: 


Word 8: 
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The programer specifies the number of 
bytes of data to be transferred in 15 bits 


of this word. Bit zero is not used. 


The programmer specifies the byte count 


in bits 0 through 15 (must be an even 


number of bytes). 


This 16-bit field is used to specify the 

base address (i. e., the location of the 

first byte) of the Translate Table if the 
Translate function is specified in the | 

MODE field of word 1. 


Bits 0 and 1 are spares; bits 2 through 


6 specify the track address; bits 7 
through 15 specify the cylinder address. 


If the Search function is specified in the 
MODE field of word 1, the programer 
must specify the 16-bit base address 
(i.e., the location of the first byte) of 
the Search Table to be used by the monitor. 


Bits 0 through 10 are spares; bits 11 
through 15 specify the sector address. 


(Spare) 
(Spare) 


Bits 13 - 15 of this word are used to 
specify an extended identification number 
for a specific device on a device con- 
troller to which multiple devices may be 
attached. For example, four cassette 
tape devices may be attached to one con- 
troller. The LUN ID extension identifies 


the specific drive to be used, as follows: | 


Cassette 


i 

© 
>) 
© 


Disc 


Hou nm wou 
— 
© 
— 


Table 2-6. Device Function Field Settings of Bits 3-7 in Word I of the FIOB 
Function Field 
Bit Settings 


Device Function 
Bit 3 4 5 


CARD READER READ HOLLERITH 00100 


IPARS ADAPTER 
CHECK CRC CHARACTER AND 
START RECEIVE 
START TRANSMITI - NO CRC 
TRANSMITTED AT BYTE 
COUNT ZERO 
START TRANSMIT2 — CRC 
TRANSMITTED AT BYTE 
COUNT ZERO : . : 
CONTINUE TRANSMITTING DATA 
1 - GRC NOT TRANSMITTED AT 
BY TE COUNT ZERO | 
CONTINUE TRANSMITTING DATA 
2 -CRC TRANSMITTED AT | 
BYTE COUNT ZERO | 
SEND NEW SYNC PULSE C000 0 


TELETYPE/ READ (teletype full duplex mode) 00000 
TERMINET | | 
WRITE (teletype full duplex 00001] 
mode) | 
WRITE (terminet simplex mode) 0000 1] 


READ 
WRITE 
BACKSPACE | 


CASSETTE 


REWIND 


START RECEIVE (look for sync) 


CONTINUE INPUTTING RECEIVED 
DATA | 


[aecmvnsroroar | oon y 
| TRANSMIT IDLES “45 | | eh or al 
Serer 


TRANSMIT STOP DATA 


SEND NEW SYNC PULSE 


223229 


Table 2-6. Device Function Field Settings of Bits 3-7 in 
Word 1 of the FIOB (cont) 


Device . 


WRITE 


Function - 


DISPLAY KEYBOARD | READ (chained) 
DISC | 


NOTE. 


Function Field 
Bit Settings 


Bit 3 is used to specify chaining of certain I/O commands, 
where: 0 = no chaining permitted and C = chaining per- 
mitted. To specify chaining, a one bit is set in bit 3. 


When the programer issues an IOACT re- 
quest, the FIOB information is accessed by the 
IOCS monitor, which extracts the I/O request 
information and enters it into the next entry of 
the IOCQ Table, described below. When the 
queued I/O request is to be performed, the 
monitor extracts the IOCQ entry information and 
places it in the internally-stored Physical I/O 
Table (PIOT) for use of the device controller, 


which performs the I/O action request. 


3.4.2 Input/Output Control Queue Table 


Definition 


For each I/O device channel to be used by 


the program, the programer must set up an LOCQ 


Table area in which entries for each I/O request 
can be made. The IOCQ entries are a fixed for- 


mat and size, as shown in figure 2-4. 


The first word of each IOCQ entry is specified 


via a source statement by the programer, as 


follows: 


Word 0: Link Field (16 bits). The pro- 


gramer specifies the address of | 


the next 1OCQ entry in this 16-bit | 


field. 


_ Word 9 


A storage area must be reserved for the re- 
maining nine words. The Logical and Physical 
Status fields in Word 1 are used by the monitor 
and the device drivers to report the status of I/O 
requests, as shown in tables 2-7 and 2-8, 
respectively. These status fields can be tested 
by the program to determine the status of each 


I/O request. 


The remaining words are filled from the 
FIOB by the monitor when an IOACT request is 
issued by the program, and used by the specified 
hardware device controller when the I/O action is 
performed. 


jb esila eee bebe be 


Bits 


Word 0 

Word 1 | Logical Status Basia Stn 
Word 2 
Word 3 | BUFFER ADDRESS (starting byte) 

Word 4 BYTE COUNT _ 

Word 5 TRANSLATE TABLE BASE OR DISC ADDRESS 

Word 6 SEARCH TABLE BASE OR DISC ADDRESS 

Word 7 

Word 8 © 


Figure 2-4, Format of Input/Output Contro 
Queue (LOCQ) Entries — | 
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Table 2-7. IOCQ Logical Status Codes 


Significance 


Processing completed. This code is the initial value of the 
logical status field. When the program completes I/O re- 
quest processing, it should reset the logical status code to 0. 


I/O pending. This code is set by the IOCS monitor when the 
I/O request has been queued in the IOCQ table. 


1/O initiated. This code is set by the device driver when the 
hardware has started the I/O action. 


I/O completed* The physical status field can be checked to 
see which kind of I/O completion has occurred. 


*An exception in this case is that the display keyboard service routine 
sets the status to 0 onan I/O completed, rather than setting it to 3. 


Table 2-8. IOCQ Physical Status Codes 


GROUP STATUS SUBGROUP STATUS 
Code asc athe Code 
(bits 8-11) Significance (bits 12-15) ' Significance 


0 Normal completion Search requested and — 
byte found 

Byte count = 0 

EOR | 

EOR with attention 

{| Noncompare  ___| 
Seek initiated (disc) _ 


None 


] Illegal operation for this 
| device 


2 Attention (hardware alert 
condition) 


None 

Hopper check (CR) 
Motion check (CR) 

CIG tumble table entry 
made 

CIC system reset 

End of tape (EOT) 


Beginning of tape 
Write protect 
Data transmission 
problem 

Motor off 
Abandoned call 
Break © 


Dro woynynunubh WNHO 


None 

a. Device not opera- 
tional, or 

b. Present order 
chained, next byte 
count = 0 

Data lost 

Check character bad 

Read check (CR)/ error 

Qlegal interrupt 

Format error (disc) 

Punch tape out 

Disconnected 

Parity error 


| Error (hardware detected) 


WOONAOAWN + 
= 2 \ a . x 
| 


jos 


2: 3-31 


3.4.3 Special Functions 


In addition to the basic I/O services of 
CLOSE, OPEN, INITialize, and IOACT, the 


PTS-100 hardware provides two special functions: 


@ The Search function allows the programer to 
test for the occurrence of particuar control 
characters within the I/O character stream, 
and specify interrupt conditions when these 


characters appear. 


e The Translate function allows the programer 
to specify input/output code conversion (i.e., 
to specify that input/output data characters 
are to be converted to or from the ASCII code 


used internally by the PTS-100). 


These functions are specified in conjunction 
with the IOACT service request by entering a code 
in the MODE field of Word 1 in the FIOB (see sub- 
section 3.4.1). They use numerically ordered, 
programer-defined byte tables containing the con- 
The Search and 
Translate Table addresses are specified in words 
5 and 4, respectively, of the FIOB. The MODE 


field code specifies whether the hardware is to 


trol and/or conversion codes. 


use a common table or separate Search and Trans- 
late Tables. 
issued, the IOCS monitor accesses the FIOB and 


When an IOACT service request is 


moves the Search and Translate Table base 
addresses to the LOCQ. When the IOCS is ready 
to start the I/O device action, it moves the base 
addresses into words 3 and 4 of the PIOT. Thus, 
by the time the hardware device controller is 
ready to perform the specified action, the Search 
and Translate Tables are accessible to the con- 
troller. The definition and usage of Search and 


Translate Tables are presented below. 


on fe ee: The Search 


function enables the programer to specify inter- 


Search Table Definition. 


rupt condition settings when particular control | 
characters appear in the data stream flowing 


through a device controller. The interrupt con- 


dition settings are specified by control codes 
stored in given byte locations within a programer- 
defined Search Table, whose total length is 
determined by the length of the 1/O data code, as 


follows: 


Code Length Table Length 


8 bit 256 bytes 
7 bit 128 bytes 
6 bit 64 bytes 
Cle fess ses-s 


In the Search Table, the byte location of a 
given control code must correspond to the 


following: 


search table base address 
+ numeric value of the control data 


character 


That is, the base address (the location of byte 0) 
of the Search Table is offset (i.e. , incremented) 
by the value of the data character passing through 
the controller to determine the byte location of 
the corresponding control code. To effect a hard- 
ware interrupt condition setting, tue left-most | 
bit (MSB) of a control code must be set to one. 
Figure 2-5 illustrates the Search Table format 


and control code bit settings. 


OFFSET* SEARCH CODE 
0 00000000 
10000000 
2 | 00000000 
3 00000000 

253 00000000 
254 10000009 
255 0000°000 


: | 
Value of current data character 
passing through controller 


Figure 2-5. Search Table Format for 8- Bit Code 
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When the Search function is specified in the 
MODE field of Word 1 in the FIOB, each character 
flowing through the device controller is agéa to 
When 
the code is located, its MSB is tested. If it is 


locate the control code in the Search Table. 


equal to 1, an interrupt condition is set for the 
device. If the MSB = 0, the next character is 


selected and the Search function is repeated. 


Notice that the byte locations corresponding 


to offset characters lio 


contain MSB's equal to 1; hence, when a data 


and 254, 4 in figure 2-5 


character whose value is equal to 1 or 254 passes 
through the specified device controller an 


interrupt condition will be set. 


The Search Table may be combined with the 
Translate Table when the data codes used are 7 
bits or less in length. That is, if the actual 
translate ohawaeter codes are no more than 7 bits 
inlength, the first bit of the 8-bit field may be 
used as the control code setting on which to test. 


For 8-bit code, separate tables must be used for 


the Search and Translate functions. 


3.4.3.2 Translate Table Definition. The 
Translate function allows the programer to specify 
| conversion of data characters to or from the 7- 

bit ASCII code used internally inthe PTS-100. 
When a code other than 7-bit ASCII is to be read 
into the main memory of the PTS-100, the pro- 
gramer must set up a Translate Table containing . 
ASCII characters whose byte locations are equiva- 
lent to the value of the input data characters. 

That is, the base address (the location of byte 0) 
of the Translate Table is offset (i.e., incremented) 
by the value of the input character passing through 
the controller to determine the byte location of the 
conversion code value that is to replace the input 
character value. When output data is to be con- 
verted from ASCII to another code, a Translate 
Table must be set up in which the values of the 
ASCIU characters correspond to the byte locations 
in which the associated values of the output con- 


version codes are stored. The format ofa 


Translate Table for 8-bit code conversion is 


illustrated in figure 2-6. 


* 
OFFSET CONVERSION 
CODE VALUES 
0 
| 
2 
3 
253 
254 | Value in 
a ) Byte 254 
255 


Value in 
Byte 255 


* 
Value of current data character 
passing through controller 


Translate Table Format for 8-Bit 
Code Conversion 


Figure 2-6. 


- When the Translate function is specified in 
the MODE field of Word 1 in the FIOB, the device 
controller matches each data character in the I/O 
stream with the corresponding position in the 
Translate Table and replaces its value with the 


conversion code value stored in the byte location. 


If the Translate Table contains conversion 
codes of 7 bits or less in length, it may be used 
simultaneously as a Search Table. Thatis, the 
MSB of each byte location is available for use as 
an interrupt condition indicator, since conversion 
code values are right-justified in the byte fields. 
if 8-bit code is to be converted, a separate Search 


Table must be defined for Search function use. 


232-53 


The Translate Table length is determined by 


the length of the code to be converted, as follows: 


Code Length Table Length 


8 bit 256 bytes 
7 bit 128 bytes 
6 bit 64 bytes 
CLC es ia 8 Ses 

3.4.4 Monitor Service Calls 


When the application programer wishes to 
initiate any of the basic I/O device services for 


his program he must issue a monitor service call 


OP CODE 
FIELD OPERAND/COMMENTS FIELD 


statement, followed by the necessary number of 
arguments to effect the desired device service. 
When an MSC statement is encountered in a pro- 
gram, processing control is transferred to the 
IOCS monitor, which performs the specified ser- 


vice, as described in the following subsections. 


3.4.4.1 Device Initialization Service. The 
initialization service requests the monitor to 
reset all I/O devices on the system. This service 
should be requested at the beginning of a program 
or before an interrupted program is restarted. 
Three statements are required in the source pro- 
gram to effect device initialization, as shown in 


the diagram below. 


SEQUENCE 
NUMBER FIELD 


(label) A MSC A (comments) 
A DEC A 2 A (comment) (xxxxxxxx) 
AADC A (Symbolic tag 
bsolute address (return address) 
Expression 
COL COL COL 
] 6 73 


The MSC statement transfers control to the 
IOCS monitor. The DEC statement with the 
decimal constant 2 in the operand field specifies 
that the monitor is to perform the initialization 
service for all devices on the system. The ADC 
' statement operand specifies the object program 
location to which the monitor is to return control 


when the service is completed. 


When the monitor receives control, it 


initializes all I/O devices on the system as follows: 


e Issues a STOP I/O command to every device, 


thus terminating any I/O operation in process. 


e Sets the PCB's logical status bits to the 


initial condition for all devices. 


.) Enables interrupts. 


3.4.4.2 Device Open Service. The device 
OPEN service requests the LOCS monitor to 
initialize a specific device and its associated 
monitor software routines so that subsequent pro- 
gram IOACT requests may be serviced. The 
statements necessary to effect an OPEN device 


service are shown below. 
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(label) A MSC A (comment) 
A DEC A 6 A (comment) 
Symbolic tag 
A ADC A Absolute address 
. Expression 
| A ADC A Symbolic tag 
Loe, Tag! A HEX A LUN ID 


A ADC A 
A RESV, 00AQ 2 bytes 


The DEC statement with the decimal constant 
6 in the operand field specifies that the monitor 
is to perform the OPEN service for the device 
specified by the LUN ID in the HEX statement, 
to which the monitor is directed in the preceding 
ADC statement. The last ADC statement spe- 
cifies the starting address of the programer- 
defined IOCQ table for the device. The RESV 
statement reserves a two-byte field into which the 
IOCS monitor can store a code indicating that an _ 
error occurred during the attempt to service the 


OPEN request. 


When the monitor receives control to service 
an OPEN request, it performs any initialization 
for the device, and its associated software 
The monitor resets all relevant status 


fields within its internal tables and the IOCQ so 


routines. 


that obsolete I/O requests will be eliminated. 


(label) A MSC A oe 
A DEC a 7 A (comment) 
Symbolic tag 
A ADC A JAbsolute address 
Expression 
A ADC A FIOB address 
COL CoO L 
l 6 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


LOCQ Table Address 


(xxxxxxxx) 


(return address) 


If the specified device is a full duplex com- 
munications device, separate OPEN service 
requests must be issued to initialize transmit and 
receive actions. That is, each action is treated 
as though it were to be performed on a separate 
device, each with its unique LUN ID and asso- 


ciated IOCQ table entry. 


3.4.4.3 I/O Action Service. The IOACT service 
requests the monitor to initiate specific I/O 
actions of which the device is capable, such as 
read, write, rewind, backspace, etc. Associated 
with each IOACT service request is a programer- 
defined FIOB Table (see subsection 3.4.1) that 
specifies the parameters to be used by the moni- 
tor in servicing the request. The source state- 


ments necessary to effect an IOACT service are 


shown below. 


SEQUENCE | 
NUMBER FIELD] 
(xxxxxxxx) 


(return address) 


CO L 
73 
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The DEC statement with the decimal constant 
7 in the operand field specifies that the monitor is 
to perform an IOACT service on the device whose 
associated FIOB is referenced in the operand field 
of the last ADC statement. The first ADC state- 
ment specifies the address in the object program 
to which control is to return when the IOACT 


request has been serviced. 


When the monitor receives the IOACT ser- 
vice request, it accesses the specified FIOB, 
enters the I/O request into the IOCQ, and changes 
the IOCQ's logical status field setting from 
"Tnitial'' (= 0) to "I/O pending" (= 1). When the 
device controller actually starts the specified 
action, the logical status field setting is changed 
to "I/O Initiated" (= 2). When the I/O request has 
been serviced the logical status setting is changed 
to "I/O Completed" (= 3). 


LABEL 
FIELD 


OP CODE 
FIELD 


(label) A MSC A (comment) 
A DEC A 1 A (comment) 
Symbolic tag 
A ADC A Absolute Address 
Expression 
| 1, ADC A ‘Symbolic tag 


‘Symb. TagiA HEX a LUN ID 


OPERAND/COMMENTS FIELD | 


Once the IOACT request has been serviced, 


‘the programer should ensure that the logical 


status field is cleared to zero (initial setting) to 
signal the monitor that the IOCQ entry is again 


available for use. 


If an IOACT request cannot be serviced by 
the monitor, an error code is passed to the pro- 
gram via the error code field in the right- most 
byte in Word 0 of the FIOB. No other FIOB fields 
are altered by the monitor. After control is re- 
turned to the program, the error code field should 
be tested. 
3.4.4.4. Device Close Service. The device 
CLOSE service requests the monitor to close 
down a device at the end of a job or to facilitate 
anerrorrecovery. The statements necessary to 


effect a device CLOSE service are shown below. 


SEQUENCE 
NUMBER FIELD 


(xxxxxxxx) 


(return address) 
\ 


eg t 
| | A RESV,00 4 2 


con GOL 
1 6 


The DEC statement with the constant 1 in the 
operand field specifies that the monitor is to per- 
form the CLOSE service for the device specified 
by the LUN ID in the HEX statement, to which the 
monitor is directed by the preceding ADC state- 
ment. The RESV statement reserves a two- byte 
field into which the monitor can store a code to 
indicate that an error occurred during the attempt 
to CLOSE the device. 


When the monitor receives control to service 


a CLOSE request, it performs all steps necessary 


(error code field) | 
+ 


COL 
73 


to terminate operation on the specified device. 
The monitor sets all status fields in its internal 
tables to indicate a device ''closed'" condition. 
It does not, however, clear any of the fields in 
the IOCQ, since this table may be examined for 


error analysis by the program. 


When a device has been closed in this 
manner, it must be initialized by an OPEN ser- 
vice request before subsequent IOACT service 


requests can be issued to it. 
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3.4.4.5 System Exit Service. The EXIT loading, etc. The EXIT service is effected by 


service requests the monitor to log the end- of- issuing an MSC statement followed by a DEC 
job and loop at location 0 until some manual statement with a decimal constant 0 in the 
intervention specifies a new processing step, operand field, as shown below. 


such as the use of the Debug program, program 


OP CODE SEQUENCE 
FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A MSC A (comment) (xxxxxxxx) 


A DEC A 0 A (comment) 


COL COL COL 
] 6 73 
3.4.4.6 Watchdog Timer Service. The Watch- WATCHDOG TIMER switch is set to ENABLE, 
dog Timer service call controls or interrogates The source statements necessary to effect a 
the optional Watchdog Timer if the feature board Watchdog Timer service call are as follows: 
LABEL OP CODE SEQUENCE 
FIELD FIELD OPERAND/COMMENTS FIELD NUMBER FIELD 
(label) A MSC a (comment) (xxxxxxxx) 
A DEC a 3 
A ADC A Symbolic Tag 
Absolute Address (return address) 
Expression 
A ADC A Symbolic Tag 
Symb. Tag| A DEC A Request Code 
A HEX aA 0 (power status field) 
A RESV,00 A 2 (error field) 
COL COL COL 
1 6 73 
The DEC statement with the constant 3 in the second DEC statement specifies the nature of the 
operand field specifies that the monitor is to request as follows: 


control or interrogate the Watchdog Timer. The 
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WDT 


Request 
Code | Meaning 

] Reset Watchdog Timer — must be given at least once every 34 seconds 
or automatic program restart will occur. 

2 Start Watchdog Timer — turns Watchdog Timer on under program 
control and automatically initializes counter to zero, 

3 Stop Watchdog Timer — turns off Watchdog Timer under program 
control. This should be reserved for special cases since the 
watchdog capability is disabled when turned off, 

4 Read power status — power status is interrogated and the reading 


storedin. the power status field. 


If any other request code is specified, an error code of 1 will be placed in the error field. 


3.4.4.7 Channel Interface Controller (CIC). Channel Interface Controller. The necessary 
Service. The CIC service call tests or resets source program statements are as follows: 


busy or off-line bits of devices attached to the 


LABEL | OP CODE | | SEQUENCE | 
FIELD FIELD. |CPERAND/COMMENTS FIELD NUMBER FIELD 


(label) A MSC A (comment) 
A DEC A 4A (comment) 


- (xxxxxxxx) 


Symbolic Tag 


A ADC a Absolute Address (return address) 
Expression 
A ADC A Symbolic Tag 
Symb. Tag A HEX A LUN ID 
A DEC A CIC Request Code 
A HEX A 0 (status field) 


ARESV, 00A 2 (error code field) 


COL COL | | | cb 
3 


The DEC statement with the constant 4 inthe ment) of the device specified by the LUN ID in 


operand field specifies that the monitor is totest the first HEX statement, to which the monitor 
or reset the busy or off-line bits (according to. is directed by the preceding ADC statement. The 
the CIC request code in the second DEC state- CIC request code must be one of the following: 
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wedge Meaning 
] Test and set busy bit — the status of the device busy bit 


(1 = busy, 0 = not busy) will be placed in bit 0 of the status field 
and the remaining bits are undefined. Then the device busy bit 
will be set. 


2 Reset busy bit — the device busy bit will be reset. 


3 Test and set off-line bit — the status of the device off-line bit 
(1 = off-line, 0 = on line) will be placed in bit 0 of the status 
field and the remaining bits are undefined. Then the device off- 
line bit will be set. 


4 Reset off-line bit — the device off-line bit will be reset. 

When the routine is executed, the specified IOCS will return an error code to the error field 
action is taken unless an unassigned LUN ID or and take no other action. The error codes are 
CIC code was specified. If either error occurs, as follows: 

CIC 
Eirror 
Code Meaning 
0 No error 
1 Illegal request code 
2 No such LUN in this system 
3.4.4.8 Device Sensing Service. The device source statements necessary to effect a device 
sensing service call requests the IOCS monitor sensing service call are as follows: 


to sense the status of a specific device. The 


(label) A MSC (comment) Gea 
A DEC A 5 A(comment) 
Symbolic tag 
A ADC A Absolute Address (return address) 
Expression 
A ADC aA _ Symbolic tag 
Symb. Tag A HEX 4 LUN ID 
A HEX a 0 (status field) 


: A RESV,00 A 2 (error code field) | 

t+ + — 4 

COL COL | | | | — CoOL 
1 6 | | | - 43 
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The DEC statement with the constant 5 in the 
operand field specifies that the monitor is to 
sense the status of the device specified by the 
LUN ID in the first HEX statement, to which the 
monitor is directed by the preceding ADC state- 
ment. When the routine is executed, the device's 
hardware status is returned to the status field, 
unless an unassigned LUN was specified, in 
which case an error code of 2 is returned to the 
error field. (If no error occurred the error | 


field setting remains all zeros. ) 


LABEL | OP CODE  |opERAND/COMMENTS FIELD 
FIELD | FIELD | | 


(label) A MSC A (comment) 

A DEC a (comment) 
Symbolic tag 

A ADC a Absolute Address 
Expression 

A ADC A Symbolic tag 

Symb. tag} A HEX A 0 (error field) 

A HEX A LUN ID (first LUN of group) 

A HEX A Interrupt Level 

A HEX A List of Drivers 

A EXREF A List of Drivers 

A HEX a First device address* 


A HEX A 


Second device address* 


Last device address* 


FFFF (sentinel defining end of group) 


3.4.4.9 Reconfiguration Service. The re- 
configuration service call changes the addresses 


of one or more peripheral devices which may 
include serial printers, card readers, modems, 
magnetic tape cassettes, and display keyboards. 
All peripherals of the same type are handled as 
one group. Therefore, the programer should code 
one reconfiguration call per group. Reconfigura- 


tion is done only at device initialization time. 


The source statements necessary to effect 


a reconfiguration service call are as follows: 
SEQUENCE 
NUMBER FIELD 
(xxxxxxxx) 


(return address) 


& 
COL 
73 


*The devices will be placed into the PCB's in the sequence given in the parameter list. 
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The following drivers support reconfiguration: 


fIDPM__ for multiple serial printers 
#IDCM for multiple card readers 


fIDMM for multiple modems 


#IDSR | for special display keyboard receive 


#IDCA, for cassettes 


Error codes are as follows: 


0 = noerror 


I 


no such LUN in this system 
PCB overflow 


i 


3.5 Disc Logical Input/Output 


The use of a disc storage device with the 
PTS-100 requires a specialized IOCS for disc 
in addition to the usual system IOCS monitor. 
The logical IOCS for disc has two interfaces: 


one with the user and one with the disc. The 


interface with the user is through macro calls, 


described in subsections 3.5.3 and 3.5.4, The 


interface with the disc is handled through the 
physical IOCS monitor. 


Before a disc is used witha PTS-100 
system, it must be formated with the Disc 
Volume Preparation program, and all files 
that are to be accessed must be allocated with 
the Disc Allocator program (see Parts 1 and 3 
of this manual). Then the disc is ready to be 


written and read by a program incorporating 


the disc logical I/O macros. Any program using 


the disc logical I/O must contain four types of 
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macros: the file description macros, main process - 


ing macro, action macros, and status macros. 


3.5.1 User File Area 


The user file area consists of the parts of 
the disc not occupied by the Volume Label or 
Volume Directory. The user file area is divided 
into one or more files, as indicated by the 
Volume Directory. Files are established, 
initialized, altered in extent, or deleted by the 
Disc Allocator utility program. A file may be 
one of three types: sequential, random with 
keys, or random without keys. All files start 


and end on cylinder boundaries. 


3.5.1.1 Sequential Files. A sequential file 
consists of a series of records written and read 
in physical sequence. The records may be 
fixed or variable in length. Records are packed 
densely into the allocated file area, in sucha 
way that no disc space is wasted. Thus, a 
record may span two or more sectors, or 


several records may occupy one sector. 


The last record in a sequential file, the 
end-of-file record, is marked by a special 
configuration in its first word: FEDC, ¢- It is 
automatically written at the time the Close 
macro is executed. This record marks the 
end of the written portion of the file, not the 
end of the allocated file area, which is indicated 


by an address in the Volume Directory. 


In files containing variable -length records, 


‘the first word of each record is the length word. 


The length word gives the number of bytes inthe 


record, including the length word itself. 


De Del s.Z - Random Files. A random file consists 
of a series of records that may be accessed 
There 


those whose 


either sequentially or non-sequentially. 
are two types of random files: 
records contain keys (K type) and those whose 


records do not contain keys (N type). 


Random file records must be unblocked, and 
fixed in length. For K type files, the first word | 
of every record is a banner word, (N type files 
do not use banner words.) The banner word is 
included to permit the read and write routine to 
determine whether a particular record position 
has been written, or whether it is still in the 
original state to which it was initialized by the 
Disc Allocator utility program. A value of 
0000), indicates that the record is unused, and 
a value of 0001, , indicates that the record is 


used (i.e. that it has been written). 


Records may be of any length up to a track, 
but records always start on sector boundaries. 
Thus, if a record is not a multiple of the sector 
length (160 words), there will be unused space 
following each record. Records may not extend | 
from track to track. If the track is not evenly | 
divisible into records, ene will be unused space. 


at the end of a track. 


Random files may be written only in direct 
access fashion, but they may be read either 
sequentially or directly. The macros Open, 
Close, Read, Write, Delete, Test, and Wait may 
be applied to them. Get and Put are not applica- 


ble to random files. 


In files containing keys (K type files), each 
key value must be unique; it must be different 


from all other key values in the file. 


3.5.2 File Description Macro. 


The File Description macro is called once 
for each file that is to be accessed, It establishes 


a File Control Block, which is a work area about 
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100 bytes long, in which all information about 
the file and the current state of its processing is 
maintained by logicalI/O. The call to the file 


description macro has the following format: 


$ FCBD a,b,c,d,e,f,g,h, i,j 


where 


a = label of File Control Block; this label is 


referred to in all the action macros to 


identify which file is to be accessed. 


device number, anumber from 0-7, identi- 


i 


fying the disc drive on which the file resides. 


type of buffering 
S 


D = double buffering (may be specified 
only for sequencial files). 


— 


single buffering 


first buffer address. 


second buffer address; enter 0 if single 
buffered. 


address of file name; the address ofa 
10-byte field containing the name that was 
assigned to the file through the Disc 


Allocator program. 


address of error word; the address ofa 
one word field which will be set to an 
identifying number if an error occurs in 


processing this file. 


relative position of key in record; for 
random files of type K, the first byte, 
relative to byte 0, of a field in the record 
that is to be used as a key in searching 


for a particular record. 
length of keys} number of bytes inkey field. 


length of buffer, in sectors; the number of 
320-byte sectors that can be read or written 
at one time, based on the length of the 


buffer(s) provided. 


3.5.3 Main Processing Macro 

There is one Main Processing macro, which 
is called into a program only once. It contains 
the coding necessary to carry out actions on the 
disc files requested by the action macros, which 
are simply branches to certain routines in the 
main processing macro. The call to the Main 
Processing macro has the following format: 


$ LIOCSD a,b,c,d,e,f,g,h 


where 

a = logical unit number of disc; this must 
correspond with the LUN ID assigned 
through the physical IOCS monitor. 

b = SE if sequential files are used; omitted 
if not. 

c = GT if GETD macro is used; omitted if not. 

d = PT if PUTD macro is used; omitted if not. 

e = RN if random files are used; omitted 


if not. 


f = RD if READD is used; omitted if not. 
g = WR if WRITED is used; omitted if not. 
h = DE if DELD is used; omitted if not. 


The above parameters cause the Main Processing 
macro to be tailored to the needs of a particular 
program, omitting any portions that are not to 

be used. For example, to generate a macro for 
random reads and writes only, under LUN 3, 


include the following call: 


LIOCSD 


$ 3,,,,RN,RD, WR 
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3.5.4 Action Macros 


Action macros are used as many times as 
necessary in a program to process the disc files. 
Each macro call results in a branch to the Main 
Processing macro, followed by a series of para- 
meters. The first parameter of every action 
macro is the label of the File Control Block, 
which identifies the file to be accessed. This | 
must be the same as the first parameter of the 


file description macro for that file. 


All action macros return to the next 


sequential instruction after the calling sequence. 


There are seven action macros: Open, 
Close, Get, Put, Read, Write, and Delete. Open 
and Close apply to all file types, Getand Putapply 
only to sequential files. Read, Write, and Delete 


apply only to random files. 
3.5.4.1 Open Macro. 


has the following format: 


The Open macro call 


$ OPEND 


a,b,c 


where 


label of file control block 


b = type of open 
I = open for input 
O = open for output 
c = error exit. Location to branch to if 


uncorrectable error occurs on open. 


The Open macro must be issued before any 
accessing can be done ona file. It searches for 
the file in the Volume Directory (established by 
the File Allocator program), and places in the 
File Control Block various pieces of information 
describing the file. If the file is not open, it 


will be opened at this time. 


3.5.4.2 Close Macro. The Close macro call 


has the following format: 


$ CLOSED a,b 


Ho 


label of File Control Block 


on 
I 


error exit 


The Close macro is issued when all file 
accessing is completed. For output sequential 
files, it causes the last record to be written on 
the disc, followed by an end of file indicator. It 
also closes the Logical Unit if the re are no other 


files open. 


3.5.4.3 Get Macro. The Get macro call has 


the following format: 


$ GETD  a,b,c,d 


where 
a = label of File Control Block 


b = address of work area into which next 


record is to be moved 


c = end-file ‘exit. Location to branch to if 


end-file is found 
d = error exit 


The Get macro, applicable only to sequential 
files, causes the next logical record to be moved 
from the buffer to the specified work area. 
Buffer switching and disc reads are executed 


when necessary. 


3.5.4.4 Put Macra aT he Put macro call has 


the following format: 


$ .PUTD a,b,c 
where 
a = label of File Control Block. 


b = address of work area from which record 


is to be taken 
c = error exit 


The Put macro, applicable only to sequential 
files, causes the logical record in the designated 
work area to be moved to an output buffer. 


Buffer switching and disc writes are executed 


when necessary. 


3.5.4.5 Read Macro. The Read macro call has 


the following format: 


$ READD = a,b,c,d,e,f 


where 


label of File Control Block 


ry) 
" 


b = address of work area into which record is 


to be moved 
c = end-file exit 
d = error exit 
e = type of access 
D = direct 


S = sequential 


f = address of parameter list (zero if no | 


parameter list) 
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The parameter list is needed only for direct type 
address. 
fields: 


If present, it contains the following two 


address of key field in program 


relative address 


The Read macro is applicable only to random 
files (type K or N organization). Its function is 
to input one record from the disc and place it in 
the indicated work area. It is assumed that the 
file is unblocked, or that deblocking is to be 
handled by the user. It is also assumed that 


records are of fixed length. 


For N type files (no keys), the access type 
given in the call is first consulted. If the access 
type is S (sequential), the system reads the 
record following the one previously read, and 
moves it into the work area. If the last record 
was at the end of the file area, the end-of-file 
exit is taken. If the access type is D (direct), 
the relative address pointed to in the call is 
interpreted as a record address, relative to the 
first record in the file. The indicated record is 
read and moved into the work area. For example, 
if relative address is 50, then logical record 
number 50 is read. The first record in the file 


is counted as number 0. 


The Read macro operates somewhat 
differently for K type files (files with keys). If 
the access type is S (sequential), the system 
reads the record following the one previously 
If a 


sequential Read is executed after a series of 


read, and moves it into the work area. 


direct Reads, the first sequential Read obtains 
If a 


sequential Read is executed without any previous 


the same record as the last direct Read. 


direct Read's, the first sequential Read obtains 


the first record in the file. 
If the access type is D (and file type is K) 


the relative address and key fields are used. A 


key is simply a field, in some fixed position, in 
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the record, which is used in looking for a 
particular record. The logical 1/O searches 
for a match between this key field in the record 
and a key value pointed to in the call. The key 
can start anywhere ina record, and be of any 
(even) byte length. However, its length and 
position are constant throughout any one given 


file. 


The relative address is interpreted as a 
track address, relative to the first track in the 
file. The first track is relative track 0. For 
example, if relative address is 10, the logical 
I/O searches for a record with the given key 


If it is 


value, on track number 10 of the file. 
not found on that track, the logical I/O continues 
searching through the overflow area, if there is 
one. When a record is found whose key matches 
the given value, it is moved to the work area. 

If no such record is found either on the home 
track or in the overflow area, the error exit 

is taken, | 
3.5.4.6 Write Macro. The Write macro has 
the following format: 


$ WRITED 


a,b,c,d 
where 


label of File Control Block 


b = address of work area 
c = error exit 
d = address of parameter list 


The parameter list contains only the relative 


address. 


The Write macro is applicable only to 
random files (type K or N organization). Its 
function is to output one record to the disc, 
It 


operates differently for type K and N files. 


taking it from the designated work area. 


For type N files (no keys), the relative 
address is interpreted as a relative record 
address. The given record is written at that 
relative record position in the file, regardless 
of what was written there previously. For 
example, if relative address is 25, the record 
is written as record 25 in the file, destroying 
the previous record 25 if any record had already 


been written there. 


The Write action for type K files differs in 
two ways. First, the relative address is 
interpreted as a relative track address. Second 
a previously written record will not be destroyed. 
This is possible because type K files have banner 
words. A banner word of 1 indicates that the 
record has been written by logical I/O; a banner 
word of 0 indicates that it is available for 
writing. The logical I/O searches down the: 
designated track for an available position; if 
one is found, it writes the record there. If no 
space is available on the home track, the logical 
I/O then looks for space in the overflow area, 
ifany. If no space is available there either, the 
error exit is taken. 
3.5.4.7 Delete Macro. The Delete macro 


has the following format: 


$ DELD a,b,c 
where 
a = label of File Control Block 
b = error exit 
c = sueasision list sddvest 


The parameter list contains: | 


address of key field 


relative address 


The Delete macro is applicable only totype K_ 
random files. Its function is to delete a particular 
record from the file, making its space available 
for rewriting. It does so by changing the banner 
from 1to0. The record to be deleted is located 
in the same way as described under the Read 


macro for file type K and access type D (direct). 
3.5.5 Status Macros 


The two status macros, Test and Wait,do 
not result in any file accessing. One of the two 
must be used after each of the action macros to 
ensure that one action has been completed before 
the next one is requested. The Test or Wait 
macro need not follow the action macro immedia - 
tely; it must, however, be issued before another 
call can be issued. This applies to all the action 
calls, including Open and Close. | 
3..565.4 The Wait macro call has 


the following format: 


Wait Macro. 


“§ WAITD a 
where a_ is the label of the File Control Block. 
The Wait macro assures completion of the last 
action on the designated file. Control remains 
in the logical I/O until the last action has been 
completed. Only then will an exit take place to_ 


the next sequential instruction. 


3.5.5.2 Test Macro. The Test macro call has 


the following format: 


—$ TESTD a,b 


a = label of File Control Block 


b = address of indicator word 


2: 3-46 


The test macro provides an alternate means of 
checking for the completion of an action macro. 
The logical I/O sets the designated indicator 
word to 0 if action is incomplete, or to 1 if the 
action is complete. The indicator word can 
then be tested by the main program to decide 


whether another action macro can be executed. 
3.5.6 Error Indicators 
Whenever an error exit occurs, the error 


word (item g, subsection 3.5.2) designated in 


the file description macro is set as follows: 


Eirror 

Code Meaning 

0001 Cannot open Logical Unit specified. 

0002 File name not found in Volume 
Directoryse 

0003 Previous action not completed 


before call for new action. 


0004 


0005 


0006 


0007 


0008 


0009 


0010 
0011 
0041 
0043 


0046 
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Error 
oge: 


Me aning 


File not properly opened for 
requested action. 


Attempt to write beyond end of 
file area. 


Requested key not found in random 
file. | 


Random access file write overflow; 
requested track and overflow area, 
if any, are full. 


Incorrect file organization for 
requested action. 


Attempt to access outside of random 
file; relative address too large. 


Invalid operation. 

Byte count too large. 
Device not operational. 
CRC/rate error. 


Format error. 


Section 4. 


The PTS-100 programer may develop sets 
of generalized statements that may be used to 
create specialized sets of statements according 
to predefined limits and formats. Such gener- 
alized statements sets are called macro routines, 
which are assembly language program segments 
defined to perform processing for any number of 
other program segments into which the routines 
can be incorporated at assembly time. That is, 

a macro routine is a set of Assembler source 
statements that may be ''called" by other program 


segments. 


For purposes of discussion, macro routines 
have been classified herein as basic macro 
The 


structure and use of macro routines is described 


routines and extended macro routines. 


in detail in this section. 


4.1 Basic Macro Routine Structure 


Basic macro routine structure is as follows: 


Statement 1: This statement must identify 
the program segment as a macro routine as 


follows: 


e. The question mark (?) character must 


appear in column | of the coding form. 


@ The unique name of the macro routine, con- 
sisting of from 1 to 8 characters, must be- 
gin in column 2. The routine name may be 

composed of any characters in the PTS-100 


character set (see Appendix A). 


The format of the first statement in the 


macro routine then, is: 
? macronam 


beginning in column l. 


MACRO ROUTINES 


Statement 2 through Statement n: The body 
of the macro routine begins with statement 2 and 
ranges through statement n. Any source language 
statement may appear in the body of the macro 
routine. In addition, these statements contain 
dummy arguments in the form of decimal num - 
bers, from 1 to 99, enclosed in parentheses. 

The parentheses identify dummy arguments to the 
Assembler; the numeric value within a given set 
of parentheses dictates the sequential order in 
which an actual argument must appear in the 


argument list passed from the calling programs 


to the macro routines. 

Statement n+ 1: The last statement in the 
macro routine must contain END in the op code 
field. 


of the macro routine for Phase 1 of the Assem- 


This statement marks the physical end 
bler, as described in Section 5 following. 


To illustrate macro routine writing, assume 
that a number of independent programs will re- 
quire a card reading operation such as the 


following: 


1. Reada card. 


2. Test for last card and branch toa 
specified point if present, or branch 
to an IOACT service to read another 


card if the last card is not present. 


3. Branch when a successful card read 


operation has been performed. 


Figure 2-7 presents a generalized macro 
routine, named READCARD, to accomplish the 
desired card reading operation. In the sample 
routine, the operand fields of statements 2, 5, 

8 and 9 indicate parenthesized dummy arguments 
for which actual arguments must be supplied 


when the macro routine is called by another 


Statement 


Number 


program. The actual arguments will subse- 


quently be inserted in place of the parenthesized 


Once a macro routine has been coded, it 


| LABEL OP CODE 
| FIELD FIELD OPERAND/ COMMENTS 


| ?READCARD 


(1)+4 Get contents of first character 
in card. 


EF Compare for last card. 
RD Not last card. Go To read. 


(2) Specifies dummy argument for 
branch address if last card is read 
during [OCS request servicing. © 


Monitor service call. 


7 Specifies that monitor is to service 


a device IOACT request. 


(3) Specifies dummy argument for 
address to which control is to branch 
when read request has been serviced. 


(1) Specifies dummy argument for 
FIOB address to be used by IOCS 


monitor. 


4546 Constant to be used for last 
card compare. 


Figure 2-7. Sample Macro Routine 


dummy arguments by the Assembler's Phase 1 

when it specializes the macro routine for in- 4.2 Calling Macro Routines 
corporation in a given calling program. 

Once a macro routine has been placed on the 


library file, any other source programs, includ- 


must be stored on the appropriate macro library ments in the format shown below. 


OP CODE 
FIELD 


OPER AND /COMMENTS 


MACRONAM | Argument rt Argument atte , Argument :. 


As shown above, column one of the source . 


sign ($) to inform the Assembler that a macro 


program call statement must contain a dollar. op code. The operand field of the call statement 


routine is being called. The as signed macro to the generalized macro routine. The actual 


*If the macro routine is an IOCS monitor routine, it must be stored on the System Macro Library 
file. If itis a user application macro routine, it should appear on the User Macro Library file. 


file¥ to make it accessible to the Assembler for 


incorporation in any programs that call it. 


ing other macro routines, may call it via state- 


routine name must appear as the call statement 


must specify the actual argument(s) to be passed 


arguments may be any valid operands, labels, 
or op codes permitted in the respective fields of 


the affected statements. 


If two or more arguments are specified, they 
must be separated by. commas and the entire list 
of arguments must be terminated by a blank 
character. Because of the way in which actual 
arguments are associated with dummy arguments 
they are to replace, the order of appearance of 
actual arguments in the operand field is critical. 
That is, when the Assembler encounters a call 
statement in a source program, it reads the 
argument list in the operand field and constructs 
a table in which the actual arguments are inserted 
in the sequential order in which they appear in 
the list. The Assembler then locates the called 
macro routine in the input library file and copies 
each of the routine's source statements into an 
intermediate file, replacing all dummy argu- 
ments in the routine with corresponding actual 
arguments from the Assembler- generated table. 


That is, the first actual argument replaces all 


LABEL OP CODE 
FIELD FIELD 


The assembler will replace dummy argu- 
ments (1), (2), and (3) in the generalized macro 
routine with the respective actual arguments 
FIOB, TOTAL, and PRINT to produce the _ 
specialized routine shown in figure 2-8. This 
routine will follow the processed call statement 


in the calling program. 


The As sembler treats actual arguments as 
character strings; hence, they need not be | 
syntactic units. For example, an actual argu- 
ment value may be inserted as a character ina 
symbolic tag. That is, a generalized macro 
routine statement may contain a dummy argument 


such as 


JMP (7)TAG 


OPERAND/COMMENTS 


READCARD FIOB, TOTAL, PRINT 


RD 
EF 


occurrences of dummy argument (1), the second 
actual argument replaces all occurrences of 
dummy argument (2), etc. Hence, if the actual 
arguments are specified in improper order, they 
will be erroneously matched to dummy arguments 
and the specialized routine will produce unreliable 
results at execution time. At the programer's 
discretion, however, actual arguments may be 
¢ Each 


omission must, however, be indicated by a comma 


omitted from the call statement list. 
in the omitted argument's position in the list. 


If an argument list is too long to appear in 
the operand field of the call statement, it may 
be continued in successive statements by writing 
a slash (/) character in column 1, and the con- 


tinued list in the operand field. 


To illustrate the manner in which actual 
arguments replace dummy arguments, assume 
that the READCARD macro routine shown in 
figure 2-7 is called by a program containing the 


following call statement. 


LABEL | OP CODE | 
FELD ELD | OPERAND/COMMENTS 


FIOB+4 


Figure 2-8. 


Specialized Macro Routine 


and the seventh actual argument in the call state- 
ment list may be the character N, which would 


cause the JMP statement to be specialized as 


-JMP NTAG 


Field content of generalized routine statements 
and actual arguments transmitted in call state- 
ment lists may be written in the formats per- 
missible in source statements of a given type. 
4.3 Extended Macro Routine Structure 
Extended macro routines may be written to 
generate flexible specialized routines, depend- 
ing on the needs of calling programs. That is, 
statements of generalized macro routines may 


specify the following: 


e Insertion of statement labels to facilitate 
linkage between and within object program 


segments, described in subsection 4, 3.1 


e Conditional inclusion or deletion of gener- | 
alized macro statements depending upon 
the presence or absence of actual arguments 


in the calling program's argument list as 


OP CODE | 
FIELD 


LABEL 
FIELD 


FIOBMAC 


When the specialized routine is created by 
the Assembler, dummy argument (1) in statement 
1 will be replaced with the actual argument 
RFIOB. Actual arguments LUNDAT, BUFAD, 
BCT, TTBAD, and STBAD will replace dummy | 


arguments (2) through (6). Thus, once the 


RFIOB, LUNDAT, BUFAD, BCT, TTBAD, 
| STBAD | 


described in subsection 4. 3.2. 


@ Deletion of generalized macro statements 
depending upon equality testing of actual 
argument values against predefined values 
within the macro routine as described in 
subsection 4. 3. 3. a | 

4.3.1 Statement Label Insertion 

The macro routine may contain dummy argu- | 
ments in statement label fields to enable proper 
linkage between the calling program and the 
macro routine, and/or to facilitate transfers of 
control between coding sections within the spe- 
cialized macro routine generated for insertion 
in the calling program. When dummy arguments 

have been defined in label fields, the calling pro- 
gram must transmit an appropriate label to the 


routine via its argument list. 


To illustrate statement label insertion, a 
generalized macro routine to create an FIOB is 


shown in figure 2-9. 


Assume that a calling program contains the 


following statement: 


OPERAND/COMMENTS 


generalized macro routine is coded and filed, it 
can be called at any time an FIOB is needed ina 
source program by merely writing a call state- 
ment containing the appropriate arguments, the 
first of which is a label specifying the starting 
address of a given FIOB. 


: 4-4 


Statement 


Number 


OP CODE 
FIELD 


?FIOBMAC 
(1) 


on BO AO FP WD BD 


Figure 2-9. 


4.3.2 Conditional Inclusion and Deletion of 


Macro Routine Statements 


The PTS-100 Assembler can be directed to 
include or delete statements in the generalized 
macro routines, depending on the presence, 
absence, or value of actual arguments trans- 
That is, the 


programer may specify that given generalized 


mitted via the call statement list. 


statements are to be treated in one of the follow- 


ing ways: 


e Included in the specialized routine only if the 
corresponding actual arguments appear in 


the call statements list. 


6 Omitted from the specialized routine if the 
corresponding actual argument is equal to, 
not equal to, greater than, or less than a 


given value. 


These actions are communicated to the Assem- 
bler via the following notations in the form of 


dummy arguments: 


® (nC) or (nN), either of which specifies that 
the statement is to be included in the spe- 


cialized routine only if the actual argument 


OPERAND/COMMENTS 


0 Spare/error code 


(2) Dummy argument for mode, function and LUN 


(3) Dummy argument for input buffer address 


(4) Dummy argument for byte count 


(5) Dummy argument for translate table base 


(6) Dummy argument for search table base 


6 6-byte spare area 


>: 4-5 


Generalized Macro Routine to Create an FIOB 


corresponding to the nth dummy argument 
appears in the call statement list. The 
difference in the use of the dummy arguments 
C and N is that when the nth argument is pre- 
sent, it replaces the nC dummy argument in 
the specialized routine, whereas the nth 
argument does not replace the nN dummy 
argument in the specialized routine. For 


example, in the statement 


JMP (3C) 

the C in the dummy argument informs the 
Assembler that the JMP statement is to be 
inserted in the specialized routine only if an 
actual argument appears in the third position 
of the call statement list, and that if the 
actual argument is present, it is to be in- 
serted in the operand field of the JMP state- 


ment. However, in the statement 


STW (3) (4N) 


the (4N) dummy argument informs the 
Assembler that the Store Word statement is 
to be included in the specialized routine only 
when an actual argument appears in the 
fourth position of the call statement list. It 
does not specify that the fourth argument is 
to be inserted in the place of the (4N) dummy 


argument in the specialized routine. 


(nY), which specifies that the statement is 
to be omitted from the specialized routine if 
the actual argument corresponding to the nth 
dummy argument does appear in the call 
statement argument list. For example, in 


the statement: 


LDI AC,0 (4Y) 


the Y in the dummy argument informs the 
Assembler that the Load Immediate state- 
ment is to be omitted from the specialized 
routine when an actual argument appears in 


the fourth position of the call statement list. 


NOTE 


The (nY) and (nN) form of dummy 
arguments may be combined to 
specify omission of statements 
depending on the presence of one 
actual argument or the absence 
of another actual argument in the 
call list. 


(1, E or N,vv), which specifies that the 
statement is to be omitted from the spec - 
cialized routine if the nth actual argument 
is equal (E) or not equal (N) to the value of 
vv, a value specified as two characters. 


For example, in the statement: 


ADC (6) | (5, E, 01) 


the dummy argument (5, E,01) specifies that 
the ADC statement is to be omitted from the 
specialized routine if the fifth actual argu- 
ment's value is equal to 01. In the state - 


ment: 
LDW (15) (12,N,AA) 


the dummy argument (12, N, AA) specifies 
that the LDW statement is to be omitted if 
the value transmitted for the twelfth actual | 


argument is not equal to AA. 


e (n,G or L, vv), which specifies that the state- 
; ment is to be omitted from the specialized 
routine if the nth actual argument is greater 
than (G) or less than (L) the value of Wy, a 
value specified as two characters. For 


example, in the statement: 
ADC (6) (5,G,01) 


the dummy argument (5, G, 01) spe cifies that the 
ADC statement is to be omitted from the specia - 
lized routine if the value ofthe fifthactualargu- 


mentis greaterthan 01. In the statement: 
LDW (15) (12, L, 05) 


the dummy argument (12, L, 05) specifies 
that the LDW statement is to be omitted if 
the value transmitted for the twelth actual 


argument is less than 05. 


In all cases, omission of an actual argument 
from a call statement list is affected by entering 
a comma in the corresponding position in the list 
as illustrated below, where the third, fifth, sixth, 
and seventh actual arguments have been omitted. 


Trailing commas are unnecessary. 
$ MACRONAM Argl,Arg2,,Arg4,,,,Arg8 


To illustrate the flexibility provided by these 
optional directives to the Assembler, assume 
that a generalized macro routine named SERREQ, 
shown in figure 2-10, has been coded to create 
specialized routines to request services from the 
1OCS monitor. The use of the SERREQ macro 
routine to generate specialized routines to re- 
quest the INITialization, OPEN, IOACT, CLOSE, 
and EXIT services is described in the following 
paragraphs. In all cases, arguments ] and 2 
must appear in the SERREQ call statement list. 
That is, statements 1 and 2 must appear in any 
of the specialized routines. These two state- 
ments are the only ones required for the EXIT 
service request; hence, the ent statement: 


$ SERREQ _ EXIT, 00 
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Statement LABEL OP CODE PERAND/COMMENTS 


2 (2) Dummy argument for the device service request 
code. 


3 (3) (2,E£,00) Dummy argument for the return address 
in all service requests except EXIT, whose service 
request code is 00. 


4 (4C) Dummy argument for FIOB address in IOACT 
request or parameter address in OPEN or CLOSE 
requests. 


5 (5) (8N) Dummy argument for LUN ID assignment 
statement for CLOSE and OPEN requests. 


6 (6) (2,N,06) Dummy argument for 1OCQ address 
: used only in OPEN service request with service 
request code 06. 


7 RESV, (7) (8) (5N) Dummy argument for error code field for 
OPEN and CLOSE requests. 


3 END 


Figure 2-10. Generalized Macro Routine for Device Service Requests 


will create a specialized routine as follows: The call statement below 
EXIT MSC $ SERREQ IOACT1,07,RETAD2,FIOB1 
DEC 00 will create the service request shown below: 
Statement 3 is required in all other service re- IOACT1 MSC 
quests, and an actual argument must appear in DEC 07 
position 3 of all the call lists. Statements 4 ADC RETAD2 
through 7 are not required for the INITialization ADC FIOBI 


request, as shown in the call statement below. 
The OPEN service request requires all 
$ SERREO INIT. 02. RETAD]1 statements in the generalized routine and, there- 
fore, eight arguments must appear in its call 
statement list. The CLOSE service request re- 
The following specialized routine will be generated | 
quires all statements except statement 6, which 


ll stat ts 
as a result of the call statemen will be omitted from the CLOSE specialized 


INIT MSC , routine because of the (2, N, 06) test in the state- 
DEC 02 : ment (i.e., the CLOSE service request code is 
ADC RETADI1 O01). Actual argument 6 in the CLOSE call state-. 


ment must therefore be represented as a comma. 
Statement 4 is required for the IOACT, OPEN 


and CLOSE Beeuate: However, statements 5 Calls and resulting specialized routines for OPEN 


through 7 are not required for the IOACT request. and CLOSE service requests are presented below: 


OPEN CALL 


$ SERREQ OPENI,06,RETAD3,PARAMI, 
/ . LUNID, IOCQ, 00,2 


OPEN SERVICE REQUEST ROUTINE 


OPENI - MSC 
DEC 06 
ADC | RETAD3 
ADC - PARAMI 
PARAM HEX | LUNID 4.3.3 Embedded Macro-Calls 
ADC IOCQ 
RESV,00. 2 Generalized macro routines may contain one 


or more macro call statements that specify the 
names of other macro routines in their op code 


CLOSE CALL 
fields. Macro routines may not call themselves 


$ SERREQ  CLOSE!,01,RETAD4, PARAMZ2, - recursively, however, since this would cause an 
/ LUNID,,00,2 : endless repetition of the macro processing phase 


| of the Assembler. 
CLOSE SERVICE REQUEST ROUTINE | 


CLOSE] MSG | 7 Macro call statements embedded in gener- 
DEC 01 | alized macro routines may themselves contain 
ADC RETAD4 dummy arguments within their argument lists. 
ADC PARAM2 | | | This facility allows the programer to pass argu- 

PARAM2 HEX _ LUNID ments from one macro routine level to another. 
RESV,00 2 | | | 


Section 5. 


There are three versions of the PTS-100 


Assembler: 


PTS-100 Native Assembler 
Raytheon 704 Cross Assembler 
IBM 360/370 Cross Assembler. 


The applications program input requirements 
for the Assemblers are described in subsection 
5.1 below. The input to an IOCS monitor assem- 
bly run is the Assembler-formated tape file pro- 
duced by the System Generator program, 
described in Part 3 of this handbook. Processing 
and the output listing are identical for all ver- 
sions of the Assembler, as described in sub- 
sections 5.2 and 5.3. Machine requirements and 
Assembler limitations of the two Cross Assem- 
The disc 


version of the PTS-100 native assembler is de- 


blers are presented in subsection. 5.4. 


scribed in subsection 5.5 


5.1 Programer Inputs 


The inputs to the PTS-100 Assembler are 
punched card decks, each of which contains both 


of the following: 


° One assembly control card described below, 
which must contain the program name and 


may specify assembly options. 


e The source program statements, the last of 
which must be an END statement card to ter- 


minate assembly processing. 
5.1.1 Assembly Control Card Content 


The assembly control card specifies two 


types of information: 


e The program name, which must appear in 


columns 1 through 8. 
@ Assembler options, as shown in table 2-9. 


File assignments for the Assembly process are 


default, as shown in table 2-10. 


ASSEMBLER PROGRAM 


Table 2-9. 


Assembler Option Selection 


CONTROL CARD 
[Content [eorurn| 
No cross reference listing 


1. 28 : 
al 
(default) | 
Sequence checking 1 30 
Rooney snl in| Sopaoh | 
[Macros included (default) No punch 

(Macros not included — | 
Relocatable object text No punch 
Absolute object text 


Full listing,* macros ex- Nopunch }] 36 
1 
z 


panded (default) 
Full listing, macros not 
3 
| Nopunch[ 38 | 
] 
1 


expanded 
1 Nopunch] 42 
1 
| No punch 44 | 
1 
No punch 
1 


DriveNo. f 


DriveNo. ft 


OPTION 


Cross reference listing 


Error listing only 


No listing 


Machine language produced 
(default) 


No machine language produced 


Rewind - object cassette™” 


No rewind - object cassette 


eS 
Source program - card reader 


asols 


Listing - serial printer 
Listing - ASR 


Object program - cassette** 


{Disc scratch file. 1 


Disc scratch file 2 


(Disc macro file DriveNo. f | 


[Disc binary output iDriveNo. # 


Note: 


If macro calls appear in the source 
program, the programer must en- 
sure that the macro library file is 
available as input to the Assembler. 


*A full listing contains diagnostic error codes, 
object program code, and source language state- 
ments (see subsection 5. 3). 


**DTS-100 native Assembler only. 


TA dig t from 0-7; if no punch, drive 0 assumed. 


*, digit from 0-7; if no punch, drive 2 assumed. 


© Bos] 


Table 2-10. File (Device) Assignments for - @ Phase 2, which analyzes the source state- 


Assembly Processi 
y cessing ments and performs preprocessing for pro- 


gram assembly proper,.as described in 


subsection 5.2.3. 


e Phase 3, which optimizes object program 


memory storage requirements, as described 


Card Reader 
Read - 
ee | . in subsection 5.2.4. 
Tape Unit 3 | 
| @ Phase 4, which completes the construction 


ay Tape Unit 0 of executable instructions, generates the re- 
or Disc | 
Tape Unit 1 quired listing, and produces the final object 


Cassette Tape Unit 0 program code, as described in subsection 


Sears Tape Unit 1 | 5.2.3. 


Cassette | Card Punch oe | | _ 
or Paper Figure 2-11 presents a general flow overview 
Tape Punch of the Assembler processing steps, which are de- 


Serial Line Printer scribed in detail on the following pages. 
Printer 7 - : 


5.2.1 Phase 0 Processing 


| NOTE 
Device reassignment for the IBM 
360 must be effected via Job Con- | Phase 0 reads the assembly control card, its 
trol Language cards. Specific de- only input, and constructs the options table for 


vice assignment for the PTS- 100 
is effected at system generation 
time, as is device reassignment. options table specifies the following: 

On the Raytheon 704, device re- 

assignments are effected via ASR 

keyboard commands prior to pro- | . 1, The name of the program to be assembled. 
gram assembly. 


use by all other phases of the Assembler. The 


wl 
e- e ° o “ 
2. Whether a cross reference listing is desired. 


5.2 Assembly Processing 
| | oe ’ ce Whether sequence number checking is 
Assembly processing is accomplished in desired. | 
four phases if no macro processing is required, | 
or in the following five phases if macro process- 4. | Whether there are macros to be expanded. 


ing is required: 5. Whether output is to be relocatable or 


| | ; absolute. 
e Phase 0, described in subsection 5.2.1, 
which reads the control card, constructs an 6. Listing options: 
options table for use by all subsequent | 
Assembler phases, and transfers control to . Full listing, with macros expanded 
‘Phase 1 if macro proceneing is required, or , Listing of program containing macro 
to Phase 2 if no macros are present. 


calls, but no macro expansion 
) Phase 1, which processes all macro calls in 
the source program, described in subsection : 


5.2.2, and transfers control to Phase 2. “Does not apply to PTS-100 native Assembler. 


-—--a-Trereee 


Phase 2 


If control is passed by Phase 0, reads 
source statements from card reader 


If control comes from Phase 1, reads 
source images from final work file 


Analyzes each source statement to 
construct symbol and literal tables, 
assign values, allocate memory, and 
pre-optimize machine instructions 


Prepares intermediate text file and 
passes it & control to Phase 3 


’ Inter- 
mediate 
Text 
. file 


Phase 3 


Processes intermediate text file to 
optimize memory requirements 

by constructing short executable 
instructions except when long format 
is required 


Passes optimized text file and con- 
trol to Phase 4 


Source 
Statements 


Assembly 
Control Card 


Phase 0 


1. Reads Assembly control card 
Constructs options table 


3. Calls Phase 1 if default option 
indicates macro calls are present 


4, Calls Phase 2 if option indicates 
macro calls are not present 


Alternate 
Work File 


Phase 4 


options table 


options table 


Figure 2-ll. Flow Overview of Assembly Processing 


ie) 


Resolves executable instruction 


operands 
2. Completes executable instructions 
3. Generates.listings indicated in 


4. Produces or suppresses object 
program file as specified in 


User 
Macro 
Library 
File 


Phase 1 


Reads source statements and writes 
images of all non macro call state- 
ments to work file 


Replaces macro call statements 
with specialized code, using gen- 
eralized macro routines stored on 
Library tape and writes specialized 
code images on work file 


Flags macro calls within macro 
routines and recycles to expand all 
calls to specialized code ona 
second work file 


Transfers control and final work 
file to Phase 2 when ail macro pro- 
cessing is done 


e Listing of error lines only 
@ No listing. 
7. Machine ingusve output options: 
@ Machine ree to be produced 
o No machine language. 
8. Whether siisee cassette is to be rewound.» 


9. Whether source program is on cards or high 
Xe 


speed paper tape. 


10. Whether listing is on the serial printer or 
ASR. 
11. Whether object code is to be written on 


cassette or high speed paper tape. * 


Phase 0 transfers control to Phase 1 if 
macro calls are to be processed, or to Phase 2 
if no macro calls were indicated by a 1 punched 


in control card column 32. 


5.2.2 Phase 1 Processing 


Phase lis the macro processor. Its two 


inputs are: 


@ The souree program statements on punched 


cards. 
° The user macro library file. 


Phase 1 processing is performed in the | 


following manner: 


o The cards in the input deck are read one at 


a time. 


° If column 1 of a source statement card does 
not contain $ or /, indicating a macro call or 
a calllist continuation, respectively, the card 


image is written onto the output work file. 


® If column 1 of a statement contains a $, 
Phase 1 constructs an argument table con- 
taining actual arguments in the order in 


which they appear in the call statement list. 


23 


Thatis, the first (leftmost) actualargumentin 
the list appears asthe first entry inthe argu- 

ment table, followed by the secondargumentas 
the second entry; ete. Eachentryin the argu- 


ment table contains the following fields: 
Length of entry (1 byte) 
The variable-length argument value 


When all arguments in the call statement and 
any continuation cards have been entered into 
the table, Phase 1 searches the macro library 
file for the generalized routine named in the 
op code field of the call statement. If the 
named macro routine is not found in the 
library file, Phase 1 sets an N flag in the 
error code field of the macro call statement 
card image, writes the card image onto the 
work file, and reads the next source state- 
ment card. If the named routine is located 
in the library file, Phase 1 creates the spe- 
cialized routine specified in the macro call | 


statement list, as described in detail below. 


When a call generalized routine has been 


_ located in the library file, Phase 1 scans each 


of the routine's source statements for dummy 
arguments in any of the permissible forms de- 
scribed in Section 4. If no dummy arguments 
appear in a statement, or when all dummy argu- 
ments have been scanned and processed, the 
source statement is written onto the work file. 
When a dummy argument of the form (n) is found, 
Phase 1 locates the nth entry in the argument 
table and substitutes its value for the dummy 


argument, 


When a dummy argument of the form (nC) is 
found in a generalized source statement, Phase l 
locates the nth entry in the argument table, and if 
it contains a value, the value is substituted for the 
dummy argument and Phase 1 continues the state- 
ment scan or writes the specialized statement on- 


to the work file if no more dummy arguments are 


*Items 8-11 apply only to the PTS-100 native 


Assembler. 
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present. If the nth entry of the argument table 
does not contain a value, the source statement is 
not excluded from the specialized routine (i.e., 


it is written on the work file). 


When a dummy argument in the form (nY) is | 
located in the statement scan, Phase 1 locates the 
nth entry in the table. If a value appears in the 
entry, the statement containing the dummy argu- 
ment is omitted from the specialized routine. If 
a value does not appear in the entry, the source 


statement will be written on the work file. 


When a dummy argument in the form (nN) is 
found in the source statement scan, Phase 1 
locates the nth entry in the argument table to 
Lf not, 


the source statement is omitted from the spe- 


determine whether it contains a value. 


cialized routine; otherwise, it is written onto the 


work file. 


When a statement contains a dummy argu- 
ment of the form (n, E, vv) Phase 1 locates the 
nth entry in the argument table, compares its 
value to the value specified by vv, and omits the 
statement containing the dummy argument if the 
values are equal. Otherwise, the statement is 
written onto the work file. A dummy argument 
in the form (n,N,vv) causes the nth entry value 
and vv value to be compared for not equal, and 
the source statement to be omitted from the spe- 
cialized routine if they are unequal; otherwise, 


the statement is written onto the work file. 


If an embedded macro call statement (i.e., 
a statement calling another macro routine) 
appears within the generalized routine being pro- 
cessed, it is scanned for dummy arguments, 
which are processed as above. 
a MORE flag within its own coding to indicate that 
another macro processing pass is to be perform- 


ed when the current pass has been completed 


Phase 1 then sets . 


(i.e., when the END source statement is encount- 
ered in the input deck). That is, when a second 
macro routine is called within the current macro 
routine, Phase 1 writes the embedded call state- 
ment to the work file, finishes processing the 
current macro routine and the remainder of the 
input source statement deck, recycles to its be- 
ginning, then rewinds and reads its output work 
file as input to process the embedded macro calls 
encountered during the previous pass. The out- 
put source statements for the second pass are 

If additional 


ambedded macro calls are found during the second 


written onto the alternate work file. 


pass they are flagged, the alternate work file 
becomes input to another pass, and Phase 1 writes 
processed source statements to the original work 
file. At the end of each processing pass, Phase 1 
tests its MORE flag to determine if another pass 
is necessary, alternating work files and recycling 


if necessary. When the MORE flag is not set at 


the end of a pass, Phase 1 transfers the address 


of its final output work file and control to Phase 2, 


which begins the first step in assembly proper 


processing. 


5.2.3 Phase 2 Processing. 


Phase 2 is the first step in the conversion of 
source language to object language. This phase 


converts the source code to an intermediate text 


which becomes input to Phase 3. Input to Phase 


2is either: 


e The source statement deck, if control was 


passed from Phase 0 


e The final work file from Phase 2, when 


macro processing was required. 


Phase 2 reads input source statements, scanning 
each statement to identify and analyze its com- 
ponent parts and convert the statement to an inter- 
mediate text format. Each statement is processed 
according to its content and type by Phase 2, as 


follows: 


* uz 5 


e All hexadecimal, octal, and decimal constants 


“are converted to binary representation. 


° Memory is allocated as specified by ORIGIN, 
MOD, and RESERVE statements and for 


machine instructions. 


e Executable instructions are preoptimized to 


long or short format where possible. 


e Values are assigned to symbolic tags and 
placed in a symbol table for use by Phase 
3 and 4. 


e Literals are placed in four-byte entries ina 
memory table or pool. Entries in the table 
‘contain a two-byte system generated symbol, 
and the two-byte literal value itself. Whena 
Literal Origin statement is processed by 
Phase 2, the literal table entries are written 
on the intermediate text file, along with their 
system- generated addresses. A new literal 


pool is then started. 


The output from Phase 2 is the intermediate 
text file containing the processed statements and 


symbol and literal tables. 
5.2.4 Phase 3 Processing 


Phase 3 optimizes executable instructions to 
guarantee a Minimum core requirement for the 
object program. Thatis, it determines whether 
the short instruction format can be used, using 
Thus, 


Phase 3 assumes the burden of efficient core 


the long format only where necessary. 


utilization for the programer and enables sub- 
sequent program changes without inducing 


addressing errors in existing code. 


The input to Phase 3 is the intermediate text 


file, and the output is the optimized text file. 


5.2.5 Phase 4 Processing 


This phase. completes assembly processing. 
Its input is the optimized text file. Phase 4 per- 


forms the following functions: 


® Completes the construction of executable 
instructions by inserting memory address in 


operand fields. 


e Generates and prints the listing as described 
in subsection 5.3, unless no listing is spe- 


cified in the options table. 


e Generates an absolute or relocatable object 
program file unless the options table spe- 


cifies no object language file to be produced. 


5.3 Assembler Output Listing 


Depending on options specified on the assemb- 
bly control card, the Assembler produces the 


following output listing: 


e A full listing, containing the following: 


specialized macro routines 
error diagnostic codes 
object program code 


source language statements 


e A full listing of the current program without 
specialized macro routines, containing the 


following: 


error diagnostic codes 
object program code 


source language code 
e Anerror listing only 


As shown in table 2-9, the programer may specify 


that no listing is to be produced. 
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Figure 2-12 illustrates a sample page ofa 
full listing without specialized macro routines. 
The left-most column is titled ERRORS. If the 
Assembler detects coding errors in the source 
language statements, the appropriate error codes 


appear in this field, as shown below: 


Error Code Significance 


A addressing error: 


e attempt to reference non-word 


Column OP 


Column R 


Column E 


boundary with word instruction | 


@ attempt to use externally de- 
fined symbol in instruction 
other than ADC 


B symbol table overflow 
Cc constant error: 


e illegal constant type 
6 illegal constant length 


D duplicate symbol 

E symbol, as used, not defined as 
an absolute EQU 

F format error in the operand field 

G. symbol, required to be predefined, 
not predefined | 

H too many symbols in operand field 

L label error: 


e in label field, either an illegal 
start character or label too 
long 


e in operand field, label too long 
illegal op code modifier 
unrecognized op code 

macro argument error 

sequence error 

undefined symbol 


symbol is both operand of EXREF 
and defined in current program 


“wan ysoegd 


Column LOC of the listing specifies the byte 
location, expressed in hexadecimal, of the current 
The CONTENTS column indicates the 


contents of the current instruction, also express- 


instruction. 


ed in hexadecimal. The columns OP, R, E, l, 
S, and OPERAND contain the code of executable © 


instructions, where: 


Column I 


Column §S 


Column 
OPERAND 


Column SEQ 


contains the machine operation 
code, expressed in hexadecimal. 


specifies the register being used, 
where: 


0 = accumulator operation, or 
absolute addressing 
1 = program counter relative 
operation 
2 = index register 1 operation 


= index register 2 operation, 


specifies the length of the instruc- 
tion, where: 


a 
l= 


short instruction 


long instruction. 


specifies the type of addressing, 
where: | 


0 
] 


direct addressing 


indirect addressing. 


specifies the sign of the OPERAND 
value. 


specifies the displacement value 
used to form the effective address, 
where: | 


The OPERAND of a short 
instruction is a 7-bit word 
displacement value 


The OPERAND of a long 
instruction is a 16-bit byte 
displacement value. 


NOTE 


See Section 1 of part 
2 for a description 

of executable instruc- 
tion format. 


of the listing contains an Assem- 
bler- generated sequence number. 


Column SOURCE contains the source statement. 


as read by the Assembler. If the 
programer specified sequence num- 
ber checking, the programer- | 
assigned sequence number appears 
at the righthand side of the listing. 
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5.4 Assembler Limitations and Machine 


Reg uirements 


Following are the recommended machine 
requirements and pertinent limitations of the 
Raytheon 704 and IBM 360 Cross Assemblers. 


5.4.1 Raytheon 704 Cross Assembler 


The recommended minimum Raytheon 704 
equipment configuration for the PTS-100 Assem- 
bler is as follows: 

] card reader 

l card punch 

3 magnetic tape drives if the source pro- 

gram contains macro calls; otherwise 
only 2 tape drives are required 

] line printer 

1 ASR 33/35 

16K words of core storage 

Device reassignment on the Raytheon 704 may 

be effected through the use of the I/O device re- 


assignment facility of the Series 700 operating 


system. 
5.4.2 IBM 360/370 Cross Assembler 


The recommended minimum IBM 360/370 con- 


figurationfor the PTS- 100 Assembler is as follows: 


1 card reader 

1 card punch 

] magnetic tape drive 
] disc drive 

] line printer 


32K bytes of core 


The IBM 360/370 version of the PTS-100 
Assembler is designed to run under both the DOS 
and OS systems. With the exception of the system 
dependent code to produce object code in column 
binary, no system dependent macros are used, 
facilitating compatibility between systems. All 
input/output is performed through the use of a 


Cobol subroutine. 


Ze 


The IBM 360/370 version of the PTS-100 
Assembler ignores all device reassignment 
facilities of the assembly control card. Device 
reassignment is performed through the Job Con- 
trol Language. 


5.4.3 PTS-100 Native Assembler 


The recommended minimum PTS -100 configura - 


tion for the PTS-100 Native Assembler is as follows: 


] card reader 
4 cassette drives 
] serial printer 


16K bytes of core 


Optionally, the source program may be read 
from a high speed paper tape reader, eliminating 
Also, the object 


program may output onto a high speed paper tape 


the necessity of the card reader. 
punch. 


A disc may be used for intermediate text 
storage, eliminating the necessity of two of the 


cassettes. 


5.5 Disc Assembler 


For the Disc Assembler, the scratch files 
and the macro file may be on the same or different 
disc drives. To designate the drive number loca- 
tions for each file the following fields have been 
added to the control card: 


SCRATCH FILE 1 


- COL. 12 
SCRATCH FILE 2 - COL, 14 
MACRO FILE > OL; 6 
BINARY OUTPUT - COL. 18 


Columns 12, 14, and 16 should contain a number 
from 0 through 7, designating the drive on which 
the corresponding file is mounted; if there is no 
: Column 18 should 


contain the drive number for the binary output; if 


punch, drive 0 is assumed. 


this column is left blank, drive 2 is assumed. 
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The scratchand macro files must be alloca- 


ted previous to the assembly execution, using the 


DiscAllocator utility program. (If macros are not 


used, only two files need be allocated.) The follow- 


ing parameters should be used for allocation: 


Scratch File l: 


FILENAME 
DRIVENO 


FUNCTION 
FIRSTCYL 
LASTCYL 
FILEORG 
RECSIZE 


Sc earch File 2: 


FILENAME 
DRIVENO 


FUNCTION 
FIRSTCYL 
LASTCYL 
FILEORG 
RECSIZE 


I 


ASSEMBSCRI1 


same as punched in column 
12 of the assembly control 
card. 


NEW 

(see Note) 
(see Note) 
S) 

164 


ASSEMBSCR2 


same as punched in column 
140f assembly control card. 


NEW 

(see Note) 
(see Note) 
S 

164 


Macro File: 


FILENAME = DMACROFILE 


DRIVENO = same as punched in column 
16 of assembly control card. 


FUNCTION = NEW a 
FIRSTCYL = (see Note below) 


LASTCYL = (see Note below) 
FILEORG = 5 
RECSIZE = 80 

NOTE 


The parameters FIRSTCYL and 
LASTCYL are not given above, 
because the sizes of the files 
are variable. 


The sizes of scratch files I and 2, which 
should be the same size, depend on the size 


size of the program to be assembled. Allow one 
cylinder for each 78 statements in the program to 


be assembled. For example, if a source program 
contains 500 statements, a minimum of 7 cylinders 


. should be allocated to each of the scratch files. 


The size of the macro file depends on the 
total number of statements in the macros that are 
to be put into the file. Allow one cylinder for 


every 160 macro statements or fraction thereof. 
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Section 6. 


Presented below are some special techniques 
that the PTS-100 application programer may find 


useful. 


6.1 Shifting Techniques 


The Shift Right One, Arithmetic statement is 
the only shift statement provided in the PTS-100 
Assembler language. There are some techniques, 
however, that may be used to effect shifting, as 


follows: 


1. To shift left one position, add the value 


to be shifted to itself. For example, 


X'10' + X'10!' = X'20! 
X'60' + X'60' = X'CO'! 


This technique can be used for each 


multiple of two ina multiplier. For 


example, 
ne ee a 
10 10 10 10 
= 101, shifted left three 
= 101000, = 40,6 


2. To shift left or right eight positions, 
execute a Load Byte instruction, and 


then a Store Byte instruction. 


6.2 Setting Addresses 


The programer should use the Load Address 
In Index Register 2 statement to effect the follow- 


ing: 


1. Seta return address and/or an argument 


list address when calling a subroutine. 


2. Obtain the address of a value instead of 
defining an ADC for that value, if 


possible. 


PROGRAMING TECHNIQUES 


6.3 Defining Message Content 


The Text constant statement should be used 


to define the content of message buffers. 


6.4 Label Definition 


The Equate statement may be used to define 
labels, which facilitates program changes or 
corrections. For example, the statements 

START EQU * 
LDW 


may be used instead of 


START LDW KOUNT 


6.5 Constant Definitions 


In working with constants, the Load 
Immediate statement saves core storage require- 


ments. For example, 


LDI ACG, 1 
may be used instead of 


LDW One 
ONE HEX 1 
6.6 Comparison Bit Setting 


It is possible and sometimes helpful to set a 


compare bit before the actual branch, as shown 


below: 
LDI AC, 1 
CNE Two 
LDW CONSTANT 
BCB SUBR 


When this technique is used it is essential 
for the programer to remember all instructions 


that use the comparison bit. 
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Section 7. SYSTEM PROGRAMING CONSIDERATIONS 


The PTS-100 accommodates a wide range of 
external input/output device types. Input/output 
operations for application programs are managed 
by the Input/Output Control System (IOCS) monitor, 
which is a resident modular software system com- 


posed of two major components: 


© The I/O Control Nucleus, which handles 
monitor service calls from applications 


programs and services interrupts from the 
I/O devices. 


e The physical I/O routines, which handle 
requests to the specific 1/Odevices supported 


by the system. 


The I/O Control Nucleus provides two kinds 
of service: device interrupt handling and process- 
ing of service calls from application programs. 
The interrupt handling service is provided by the 
level service routines, which provide entry and 
exit control for all interrupts, save and restore 
registers, and link to the appropriate device 


service routines. 


The physical I/O routines handle all requests 
for each physical I/O device in the system. There 
is a set of physical I/O routines for each type of 
I/O device in the equipment configuration. A set 
of routines includes the device driver routine and 
the device service routine. The device driver 
routine is called when there is an I/O request in 
the logical IOCQ table and the channel for the de- 
vice is inactive. The device driver routine uses 
the information in the IOCQ entry to set up the 
physical I/O control table and to initiate the I/O 


action, 


The device service routines are assigned to 
one of eight external interrupt levels when a 
particular IOCS monitor is generated for a spe- 


cific installation. These routines determine the 


reason for an interrupt, update control and status 
fields, take any required action, and then initiate 


action on the next I/O request in the IOCQ table. 


The application program service calls are 
processed as described in Section 3 of this part 
of the handbook. | 


For any given PTS-100 installation, a hard- 
ware specialized IOCS is created by the System | 
Generation program, described in Part 3 of this 
handbook. If the PTS-100 user wishes, he may 


alter the L1OCS monitor by adding special physical 
I/O and control routines to accommodate non- 
standard devices that are not supported by the 
IOCS monitor, or he may develop his own IOCS 
monitor. In either case, an understanding of the 
interrupt system of the PTS-100 and the systems 
programing I/O and interrupt statements is re- 
quired,. as described in the remainder of this 


section. 


7.1 Interrupt System 


A multilevel interruption system provides 
eight external (device) interrupt levels and three 
internal (CPU) levels. The CPU operates ata 
given level and may be. interrupted when an 
enabled higher priority interrupt condition is 
detected. Instructions are provided to enable and 
disable interrupts, trap to a higher priority 
internal level, and return to prior levels after | 
servicing interrupts. The priority of interruption 
is shown in figure 2-13, with the highest number- 


ed level having the highest priority. 


Lhe Parity Interrupt is optional. It occurs 
when the processor hardware detects invalid 
parity on the data returned from memory. At 
the completion of the current instruction the 


interrupt is serviced and level 10 is entered. 


EXTERNAL 6 
5 EXTERNAL 5 
EXTERNAL 4 


0 PROCESSOR/INTERVAL TIMER 


Interrupt Priority Levels 
in the PTS-100 


Figure 2-13. 


The Trap Interrupt is a synchronous interrupt 
that occurs when a Monitor Service Call (MSC) 
instruction is encountered in an executing pro- 
gram, This interrupt may be issued at any level. 
The interrupt is not maskable by the Disable 
Execution of the MSC 


instruction consists of storing the present status | 


Interrupts instruction. 


and loading the program counter from the level 9 
interrupt packet. Instruction execution then re- 


sumes at level 9. 


There are eight External Interrupt signals 
in levels 1 through 8. These may be assigned to 
any configuration of input/output devices. Inter- 
rogation and resetting of interrupt conditions are 
accomplished by executing the Read Device Status 


instruction, described in subsection 7.3.2. 


The Processor Interrupt level 0 does not 
have the ability to interrupt execution at another 
level. Level 0 may only be entered via the 
Interrupt Return instruction with no higher level 
interrupts outstanding. This is the level at which 


object programs execute. 


The Interval Timer Interrupt is an optional 


external interrupt condition that occurs once 


every 67 milliseconds. The interrupt may be 


taken only when the CPU is already operating at 


level 0 with external interrupts enabled. The 
interrupt causes present status to be stored and 


the program counter to be loaded from the level 
0 packet. Processing continues at level 0. | 

The central processor may be operating at 
any of the 11 interrupt levels and is normally 
enabled for external interrupts that occur ata 
higher priority level than the present level. The 
trap and parity interrupts are always enabled. 
Interrupts of the same or lower priority than the 
present operating level remain pending. All 
external interrupts may be disabled (held pending) 
by executing the Disable Interrupts instruction. 
The processor returns to the enabled state when 


the Enable Interrupts instruction is executed. 


For each assigned interrupt level, an 
associated four-word interrupt packet must be 


set up in the format shown in figure 2-14. 


OLD PROGRAM COUNTER 


NEW PROGRAM COUNTER 


Figure 2-14. Interrupt Packet Format 


and Content 


When the processor is operating at one level 
and an interrupt of higher priority is enabled, the 
processor completes the execution of the current 
instruction and then enters the following fixed 


sequence. 


1. The value of the program counter (pointing to 
the next sequential instruction to be executed) 
is stored in the first word in the interrupt 


packet. 
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2. The old interrupt level and the condition bit 
(CB) are then stored in the next sequential 
word of the packet, in bits 4-7 and 15, 
respectively. 

3. A new value for the program counter is then 


loaded and the new interrupt level is entered. 


This sequence of events cannot be interrupted. If 
a higher priority interrupt occurs during the 
sequence, servicing is deferred until completion 


of one CPU instruction at the new level. 


An Interrupt Return instruction should be 
issued immediately following the completion of 
interrupt servicing. This causes the processor 
status to be restored to the point prior to the 
The old PC, old interrupt level, 


and old condition bit are restored by the hard- 


interruption. 


ware from the save area at the departing level. 


7.2 Interrupt Statements 


There are three statements provided for 
changing the external interrupt level at which the 
central processor is currently operating, as 


shown in table 2-l1li. 


Table 2-li. Interrupt Statements 


OP CODE | 
FIELD COMMENTS : 


(disable interrupts) | 


LABEL 
FIELD 


(enable interrupts) | 


(interrupt return) 


The DIN (disable interrupts) statement 
specifies that all interrupts at levels 0 through 8 
are to be disabled. Thatis, they are to be held 
pending so that current instruction execution can- 


not be interrupted. 
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The ENB (enable interrupts) statement spe- 
cifies that all external interrupts at levels l 
through 8 are to be enabled. That is, external 
interrupts of a higher priority than the current 
CPU operating level are to be serviced when 


they occur. 


The INR (interrupt return) statement specifies 
that the CPU is to return to the interrupt level 
that was current just prior to the most recent 


interrupt. 


At assembly time these statements are trans- 
The 
The R field 


of a given machine instruction serves as an 


lated to short machine instruction format. 


machine op code in all cases is Ol. 


extended op code to identify the specific interrupt 


statement involved, where: 


R= 00 Enable Interrupts 
R= 01 Disable Interrupts 
R= 10 Interrupt Return 


In all cases, the operand field of the machine 


instruction should be zero. 


7.3 System Programing of I/O Operations 


Input/output operations occur via direct 
memory access channels. Data, addresses, and 
status information are exchanged between the 
CPU and device controllers across a 16-bit bi- 
directional bus. The I/O controllers may initiate 
data transfers between devices and memory and 
may also initiate limited arithmetic operations to 
be performed in the CPU. These actions are 


overlapped with CPU instruction execution. 


For system programs that are to run inde- 
pendently of the IOCS monitor, (uO: statements 
are provided to perform I/O operations and 
interrogate status indicators in the I/O con- 


trollers and devices. These statements are: 


e Do IO statement, which is used to perform 


all I/O operations. 


r Read IO Status statement, which is used to 
test the operational status of devices and 
device controllers. 

7.3.1 Performing I/O Operations 

When I/O operations are to be performed 


independently of the IOCS monitor, the Do IO 


statemént must be used in conjunction with a 


Load Word statement as shown below. 


LABEL | OP CODE | P 
IFIELD FIELD OPERAND/COMMENTS 


X'0 + Device Address' 
(start I/O on DA) 


I/O Packet Address 


X'1 +Device Address' 
(stop I/O on DA) 


The operand of the LDW statement must 

_ have been previously stored by the programer. 

It specifies the start or stop command and the 
physical address of the device on which the opera- 
tion is to be performed. The format of the LDW 


operand is shown below. 


012345 67 8 9 10 11°12 13 14 15 


CMD 


DEVICE ADDRESS | | 
where: bits 4- 15 specify the physical address 


of the device, and 


bits 0 -3 specify one of the following: 


CMD = 0 specifies that an IO 
16 * e * 

operation is to start 

CMD = 116 specifies that the IO 


operation is to stop 


If CMD = 116 when the Do IO instruction is 
executed, the addressed device will be stopped as 
soon as possible and all pending or active memory 
requests from the device will be cleared. The 
IO controller for the device will be left in the not 


busy state. 


NOTE 


When a stop I/O command code is 
specified, the Do IO statement 
operand must be a symbolic tag or 
a self-referencing indicator. 


If CMD = 0,¢, the Do IO instruction operand 
must be the starting address of an I/O packet 
specifying all information necessary for executing 


the I/O operation, as described in subsection 
7.3.1.1 below. 


When the Do IO instruction to start an opera- 
tion is executed, the value in the accumulator is 
placed on the input/output data bus for the spe- 
The I/O packet address is then | 


transferred to the selected controller. 


cified device. 
The con- 
troller uses the address to locate the packet and 
perform the specified operation. The controller 
subsequently interrupts the CPU to signal signifi- 


cant device events. 


7.3.1.1 I/O Packet. 
being performed independently of the LOCS monitor, 
the I/O packet performs the functions of the FIOB 
and PIOT for operations under control of the 

IOCS monitor. 


When I/O operations are 


That is, it specifies the input/ 
output function to be performed on the device, the 
data storage area to or from which data is to be 
transferred, the total number of bytes of data 
involved in the transfer, and the base addresses 
of any Search or Translate tables to be used in the 
The I/O packet must 


start an eight-word boundary, in the format 


operation or disc address. 


shown in figure 2-15. I/O packet field content is 


discussed in detail below. 
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Bits!O 12,3 4 5 67/8 9 10 W 12 «13 14 «+15 
ORDER | BYTE INTERRUPT 
COC DOC MASK BYTE 


- Word 0 
Word | BYTE ADDRESS 
Word 2 BYTE COUNT 
Word 3 TRANSLATE TABLE BASE (TTB) OR DISC ADDRESS 
Word 4 SEARCH TABLE BASE (STB) OR DISC ADDRESS 
Word 5 ALTERNATE BYTE ADDRESS 
Word 6 ALTERNATE BYTE COUNT 
Word 7 SPARE 


Figure 2-15, I/O Packet 

The Order Byte field of the I/O packet con- 
tains the device Controller Order Code (COC) in 
bits 0 - 2 and the Device Order Code (DOC) in 
bits 3- 7. 


The Controller Order Code specifies the data 
transfer mode (i.e., whether Search and Trans- 
late functions are to be performed by the I/O con- 
troller), See Section 3 for a detailed description 


of these special functions. 


The Device Order Code (DOC) in bits 3-7 of 
the Order Byte specifies the desired I/O function 
to be performed on the specific device, as shown 


in the right- most column of table 2-6. 


The interrupt mask in the right-hand byte of 
Word 0 of the I/O packet is used to allow or 
That is, the bits of the Mask 


Byte correspond one-for-one with the bits in the 


inhibit interrupts. 


Interrupt Condition Byte (ICB) in the device con- 
troller. Hence, the programer may set a one 

bit in each position of the Interrupt Mask Byte 
where the corresponding interrupt is to be allow- 
ed and a zero bit in each bit position of the Inter- 
rupt Mask where the corresponding interrupt is 

to be inhibited. When an interrupt condition 
occurs in the device controller, the Interrupt 
Mask is ANDed with the ICB to determine whether 


an interrupt should be generated. 


NOTE 


Mask bits do not reset ICB bits. 
They merely specify whether 
interrupts are to be enabled or 
diabled for a given I/O activity. 


The possible bit settings of the Interrupt 
Mask and IC bytes are as follows: 


Bit 0 = Search requested and MSB = 1 
Bit 1 = Byte count incremented to zero 
Bit 2 = Start command issued when the 


device is in a NOT READY state 


Bit 3 = Device 'END OF RECORD" (EOR) 


Bit 4 = Attention * 


Bit 5 = Error * 


(Data overrun, data error, or 
unit check generated by the device) 


"Byte Address. Word 1 of the 1/O control 
packet specifies the address of the first byte of 
the memory storage area into or from which input/ 


output data is to be transferred. 


Byte Count. Word 2 of the I/O packet 
specifies the two's complement of the total num- 
ber of bytes of I/O data to be transferred. The 
byte count is incremented each time a byte of data 
When the 


byte count reaches zero, the data transfer is 


is transferred by the I/O controller. 


complete. 


Words 5 and 6 of the I/O packet are used to 
specify the alternate data storage address and 
byte count when I/O commands are chained. 
Command chaining is specified by a one in bit 3 
of the device order code, as shown in table 2-6. 


When command chaining is specified, the 1/O 


*The attention and error bits are summary 
bits indicating a broad classification of the type 
of interrupt that was generated, depending on the 
variable device controller conditions which may 
be indicated by individual bits in the device status 
byte, described in subsection 7.3.2. The pro- 
gramer should consult the PTS-100 Reference 
Manual for detailed information about status in- 
dicators of specific devices and controllers. 
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controller executes the first order specified by 
the DOC and uses the byte address and count 
located in words 1 and 2 of the I/O packet. Data 
transfer is halted when the byte count in word 2 
reaches (is incremented to) zero. When the next 
I/O command is executed, the I/O controller uses 
the alternate address and byte count specified in 
words 5 and 6 of the packet. Prior to issuing 
another chained set of commands against the 
packet, the programer must reset the byte 
addresses and counts in the packet. As chained 
commands are subsequently received, the con- 
troller again alternates between the byte 
addresses and counts. Oddnumbered orders utilize 
words 1 and 2 of the packet, and even numbered 
orders utilize words 5 and 6 of the packet. Com- 
mand chaining continues until a device order with 
bit 3 set to zero is executed or until a Stop I/O 


command is issued. 


Disc Address. Bits 2 through 6 of word 3 
contain the track address, and bits 7 through 15 
Bits 11 through 15 


of word 4 contain the sector address. 


contain the cylinder address. 


7.3.2 Testing Device Operational Status 


Before and after issuing a Do IO command, 
the programer should test the operational status 
of the addressed device. Status testing is spe- 
cified via the Read IO Status statement, preceded 


by a Load Word statement as shown below. 


LABEL | OP CODE | | | | 
FIELD FIELD OPERAND/COMMENTS 


LDW X'O + Device Address' 
(reads and resets status) 


Memory Address 


X'l + Device Address' 
(reads device status) 


Memory Address 


The operand of the LDW statement must have 


- been previously stored by the programer. It 


specifies the command .-code and the physical 
address of the device whose status is to be 
checked. The format of the LDW operand is 


shown below. 


01234567 891011 12 13 14 15 


CMD DEVICE ADDRESS: | | 


where: bits 4 - 15 specify the physical address 
of the device and bits 0 - 3 specify one 


of the following: © 


CMD = 06 specifies that the device 
| status is to be read and 


interrupts,are to be reset. 


CMD 


ul 
— 


16 specifies that the device 
status is to be read, but 
no interrupt conditions 
are to be altered. 


In both cases above, the RIO statement operand 
specifies the memory address to which the device 


status is to be transferred. 


When the accumulator has been loaded with a 
command code of zero and the device address, 


execution of the RIO statement causes the device's 


' status to be read and any pending interrupts to be 


That 


is, if interrupts are pending the following will 


cleared (i.e., the device status is reset). 


appear in the memory word specified in the RIO 


operand field: 


3 7-6 


If no interrupts were pending, the memory 
word will contain all zeros after the read and re- 
set interrupts operation. It should be noted in 
this case that the ICB in the controller may not 
be zero because the interrupt mask may have 


inhibited the generation of an interrupt. 


When the accumulator has been loaded with a 
command code of one and a device address, 
execution of the RIO statement causes the device 
status and the ICB to be stored in the memory, 


as follows: 


0 7 8 15 


| Device Status Byte ICB 


Device/controller status in every case con- 


sists of a minimum of two bits. The two bits are 


defined universally for all controllers and are 


bits 0 and 1 of the status byte as shown below. 


READY BUSY 

0 0 Device Not Operational 

0 1 Order In Process (i.e., 
Busy) 

1 0 Device and Controller 
Available for New Order 

1 ] (Undefined) 


— Bit 1 of device controller 


status byte 


Bit 0 of device controller 
status byte 
Therefore, only bit 0 of the status byte must 
be tested to determine if a new Do IO instruction 


may be issued. 
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PART 3. PTS-100 UTILITY PROGRAMS 


Section 1, GENERAL INTRODUCTION 


Optionally available to PTS-100 users area 
number of utility programs to aid in the devel- 
opment, checkout, execution, and maintenance 
of systems and applications processing programs. 


The following types of programs are available. 


® Iwo loader programs, the first of which is 
used to initialize the computer and to loadthe 
main loader program, which in turn must be 
used to load all assembled programs to be 


executed on the PTS-190. 


e The Interactive Debug program, which 
allows the programer to interface 
actively with it during object program 


checkout and testing. 


° The System Generator program, which per- 
forms the initial processing to produce a 
specially- tailored PTS-100 IOCS monitor to 
meet the unique applications program ‘I/O 


requirements of any given installation. 


© The Memory Dump program, available in 


two versions, which dumps main memory 


contents onto peripheral devices. 


e The Peripheral Device Dump program, 
which dumps serial binary data file records 


onto a character printing device. 


e The File Update program, which provides a 
convenient, easily used method of creating, 
maintaining, and updating files of both ob- 


ject and source programs. 


e Three disc support programs to initialize 
new discs for use with a PTS-100, allocate 
disc file space, and dump disc files onto a 


printing device. 


e The Cassette utility program, which pro- 
vides a method of storing on, deleting, copy- 
ing, positioning, and printing the contents 


of cassette magnetic tape files. 


Detailed, ''how to use'' descriptions of these 


utility programs are presented in this part of 


the Programers Handbook. 
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Section 2. PTS-100 LOADER PROGRAMS 


There are two loader programs supplied 
with the PTS- 100: 


execution 
starting 
. address 


e The Piggyback Loader, the sole function of 
which is to load the Absolute/Relocating 
Loader. / 


program/ 
segment n / 


e The Absolute/Relocating Loader, which 


must be used to load all other object pro- 


program/ 


grams, including systems programs, to be segment 4 


executed on the PTS-100. 


program/ 
segment 3 


The inputs to the loading process are: 


program/ 


e The binary code of the Piggyback Loader. segment 2 


program/ 


e The assembled, relocatable code of the segment | 


Absolute/Relocating Loader program. 


ABSOLUTE/ 
RELOCATING 
LOADER 


~ PIGGYBACK 
LOADER 
(binary code) 


° The assembled absolute or relocatable ob- 
ject code of the programs or program seg- 


ments to be loaded. 


The inputs to the total loading process for 


the PTS-100 are illustrated in figure 3-1. The Figure 3-1. Inputs to the PTS-100 Loading 
Process, Assuming the Card Reader as Input Device 


Piggyback Loader is bootstrapped into low mem- 
ory by depressing the Initial Program Load (IPL) 
button on the user console of the PTS-100. Once 2.1 Piggyback Loader | 
loaded, the Piggyback Loader initializes its 


tables and storage addresses and reads the ob- 


ject code of the Absolute/Relocating Loader, The Piggyback Loader is used to load only 
loads it into high memory, and then activates it. one program: the Absolute/Relocating Loader. 
The Absolute/Relocating Loader then reads and As mentioned earlier, the Bispyback Loader is 
loads the object program(s) from the input itself loaded via IPL bootstrap. | Once loaded, 
device. : 7 the Piggyback Loader performs the following: 


The processing, inputs, and outputs of the 
two loaders are described in the remainder of e Initializes its own tables and storage 


this section. | addresses, 


% Determines the highest available memory 
location in the computer into which it has 


been loaded. 


] Reads the object coding of the Absolute/ 
Relocating Loader from the input device 
whose physical address has been assembled 


into the Piggyback Loader. . 


e Validates input records as they are read, 
and loads the Absolute/Relocating Loader 


into the highest memory area, 


° Activates the Absolute/Relocating Loader 


when it has been completely loaded, 
2.1.1 Piggyback Loader Input 


The input to the Piggyback Loader is the ob- 
ject code of the Absolute/Relocating Loader, 
which has been assembled as a relocatable pro- 
gram by the PTS-100 Assembler. The device 
from which the Piggyback Loader is to read the 
Object code must be the same device whose 
address* has been assembled into the Piggyback 
Loader. The programer must ensure that the 
input device is operational and ready with the 
input object code before the Piggyback Loader is 


activated. 
2.1.2 Piggyback Loader Output 
The output of the Piggyback Loader is the 


activated Absolute/Relocating Loader, residing 


in high memory. 


2.2 Absolute/Relocating Loader 


The Absolute/Relocating Loader must be 


used to load all assembled systems and applica- 


tions programs to be executed on the PTS-100. 
The programs to be loaded must have been 
assembled by the PTS-100 Assembler, which 
develops object coding in the format required 
by the Absolute/Relocating Loader. The object 
programs may be absolute or relocatable, and 
may consist of one or more segments each. If 
an execution address is specified in a given pro- 
gram or program segment, it must appear at 
the end of the last segment or program loaded, 
since the Loader will immediately activate the 
given program at the specified address as soon 
as it is detected. Thatis, the Loader will turn 
control over to the loaded program and start its 
execution at the specified address. If no execu- 
tion address is specified, the Loader will wait 
for additional input to read or fora starting 


address to be specified manually. 


If additional programs or program segments 
are to be loaded after the Loader has started 
execution of a loaded program, the Loader must 


be reinitialized in one of the following ways: 


° The object program issues a call or trans- 


fers control (via an EXREF #LOADR state- 


ment) to the starting address of the Loader. 


e The programer halts the current object 


program execution via the customer engi- 
neer's console or some other direct mem- 
ory access device, enters the starting 
address of the Loader (#LOADR, as 
specified in the previous load map) as the 
new program counter setting, and restarts 


execution. 


The Absolute/Relocating Loader performs 
the following processing for a given object pro- 


gram that is being loaded: 


% , 
On systems with changeable Read Only Memories (ROMs) the input device address will be 


determined by the first changeable word of the ROM. 


Sec 


e Loads all address constants and absolute 


values, 


‘ Computes the effective addresses of all 


object program instructions. 
e Relocates a relocatable program. 


® Resolves addresses and prints a map of 
symbols named in the External Definitior 
(EXDEF) and External Reference (EXREF) 
statements to establish linkages between 


multiple programs or program segments. 


® Sets blocks of memory locations to values 


specified by object coding. 


° Performs validity checks of input data 
records and reports loading errors via an 


output listing. 


° Stores the execution starting address, if 
specified, in the level zero interrupt packet, 
and starts execution of the program via an 


interrupt return instruction, 
2.2.1 Absolute/Relocating Loader Input 


The input to the Absolute/Relocating Loader 
is one or more object program files produced by 
the PTS-100 Assembler, described in Part 2, 
Section 5, of this handbook. The object program 


file(s) may be in one of the following forms: 


punched cards 
magnetic tape records 


punched paper tape records 


Hence, the input device must be an appro- 
priate device to read the object code. The 
address of the device must have been assembled 
into the version of the Absolute/Relocating 


ste 
Loader being used. ° 


The order of applications object programs 
or program segments is program-determined. 
Certain systems programs, if present in the in- 
put device, must be loaded in prescribed orders, 
For example, the Interactive Debug program 
code should be loaded as the last program or 
program segment if it is to be initialized prior 
to starting execution of the programer's object 
program. On the other hand, if the object pro- 
gram(s) to be executed require input/output 
services from the IOCS monitor, the object code 
of the monitor should be loaded before any other 
programs. That is, the monitor is an absolute 
program, which is always loaded in low mem- 
ory. Hence, if a relocatable program is loaded 
first, and the monitor is subsequently loaded, 
the monitor will be loaded over the first part of 


the earlier program. 
2.2.2 Absolute/Relocating Loader Output . 


There are three types of output produced by 
the Absolute/Relocating Loader: 


e The loaded executable program, residing 


in main memory. 


@ A symbol map. 


e A listing of diagnostic messages signaling 


load errors detected during the attempt to 


load the object program. 


The output device address must have been 


assembled directly into the version of the 


Absolute/Relocating Loader that is being used. 


2.2.2.1 Symbol Map. The Absolute/Relo- 
cating Loader produces a listing of its own 
starting address, the program name(s), and all 
externally defined and referenced symbols in the 
program segment(s) it has loaded. A sample 
Symbol Map listing is shown in figure 3-2, Each 
symbol is listed with the memory address to 


which it was assigned by the Loader. That is, 


“On systems with changeable ROM's the input device address will be determined by the first 


changeable word of the ROM. — 


Program/ 
Symbol 


Name 


itt LOADR 


~ USERLC1 
USERLC3 | 


USERLC3 


‘Location 


3888 


0000 UD 


1055 
1055 DD 


Program/ 
Symbol 
Name Location 
 PROGNOT ~—‘1020 
~ USERLC2 1050 


USERLC4 —:1060 


Figure 3-2. Sample Symbol Map Produced 
by the Absolute/Relocating Loader 


the listing indicates the location of program 


elements after they have been relocated. Any 


undefined symbols will be shown by zero char- 


acters in the location field, to which the charac- 


ters UD (i.e., undefined) will be appended. 


Duplicate symbols will be shown with the address 


of the first definition of that symbol, and the 


characters DD (i. e., duplicate definition) will 


be appended to the location field. 


If the symbol table created by the Loader is 


too large, a symbol overflow condition occurs, 


and the attempt to load the program is aborted. 


TA ——R 


Table 3-1. 


Error 
Code 


CK 


O 


A record sequence number is 
out of order (i.e., not in order 
produced by the Assembler), 


In this case, the symbol map is produced un- 
conditionally to. indicate the last symbol pro- 
cessed prior to the overflow condition. The 
symbol table overflow condition occurs because 
the Loader starts the symbol table in high 
memory, immediately preceding the first 
location used by the Loader itself, and builds it 
downward, toward the executable object code, 
which is built upward from lower memory. If 
the symbol table storage area reaches the pro- 
gram code area before the program is com- 
pletely loaded, the Loader cannot complete the 
load process, which is aborted. If the program 
code area reaches the symbol table storage area 
during program load, a memory overflow error 
condition is declared and the load is aborted in 
the same way as for the symbol overflow 


condition. 


2.2.2.2 Error Diagnostic Listing. The 
Absolute/Relocating Loader produces an error 


coded listing of any load errors that occurred 
during the attempt to load the object program. 
The error codes, their causes, and the required 


program actions are presented in table 3-1. 


Error Codes Output by the Absolute/Relocating Loader 


Cause 


A checksum (i.e., record read) 
error has occurred during the 
Loader's input record reading. 


A read error has occurred during 
the Card Version Loader's 
attempt to read the last input 
record. 


A symbol table overflow has 
occurred and the Loader process 
has been aborted. 


A memory overflow condition has 
occurred (i.e., the object pro- 
gram is too large for available 
memory) and the Loader process 
is aborted. 


| from the beginning. 


Programer Action 


Effect a re-read of the input 
record by repositioning input tape | 
to beginning, or refeeding object 
deck, and restarting load process 
from beginning. 


Reduce number of symbols in the 
total program, reassemble, and 
reload. 


Reduce total program size, re- 
assemble, and reload. 


Correct sequence ordei of object 
code and restart the load process 


Section 3. 


The Interactive Debug Program for the 
PTS-100 System allows the programer to active- 
ly interface with it during object program check- 


out to effect the following: 


e Addition or subtraction of hexadecimal 


constants. 


Single or successive memory location 


dumps. 


: Searches of memory locations for specific 
full word values or masked searches on 
values of less than 16-bits in length. 

e Alterations of single memory location 
content to a specific value. 

° Successive memory location loading with 
specific values, 

@ Breakpoint setting and clearing. 

° Transfers of control to specific addresses 
and resumption of program execution. 

e Transfers of control to specific addresses 
with the accumulator and/or one or both 
index registers set to specific values and 
resumption of program execution. 

° Continuation of previously issued Debug 
commands. 

° Input command editing. 


Thus the programer is provided hands-on 
This 


capability allows selective examination of mem- 


control of the execution of his program. 


ory, manipulation of memory words by 
accessing and altering them, selective execu- 
tion of any part or all of the program, prepara- 
tion of active unit tests, minor program 


patching, etc. 


Paes eae | 


INTERACTIVE DEBUG PROGRAM 


The Interactive Debug program requires the 
ASR device for input and output. If some other 
device is to be used for 1/O, the RDS- supplied 
Interactive Debug program must be modified by 
replacing its ASR driver routines with the 


appropriate nonstandard driver routines. 


The Debug program interrelates with the 
programer and the executing object program as 
to the functions it is to perform. Since itis a 
slave type program it waits for input once it is 
initialized. No timers are used and there are 
no restrictions placed on the length of time be- 
tween commands or between parameter entries 
within commands. The types of functions per- 
formed and program interface with the Debug 
program are described in detail in the remain- 


der of this section. 


3.1 Inputs to the Interactive Debug Program 


There are two basic inputs required to 


initialize the Interactive Debug process: 


e The object code of both the object program 
and the Interactive Debug program, which 
are entered into the computer via the Abso- 
lute/Relocating Loader (see Section 2) from 
whatever input device is required to read 
the object code (i.e., card reader, cassette 


tape device, etc.)}. 


° The interactive debug input commands, 


which are entered one at a time via the 


ASR device keyboard. 


When the Absolute/Relocating Loader com- 
pletes loading the Interactive Debug program, it 
activates Debug, which then performs its own 
initialization and indicates that it is ready to 
receive input commands by printing the word 
DEBUG at the ASR device. That is, the only 
programer action required to initialize Debug 
is to ensure that its object code is loaded. De- 


pending on the equipment resources available in 


a particular PTS-100 configuration, there are a 
number of ways in which the Debug program may 


be loaded, as follows: 


e Ona standard PTS-100, the most efficient 
way to load the Debug program is to load 
its object code immediately following the 
object code of the program to be debugged. 
That is, the Debug program is treated as 
though it were the last segment of the Bre: 
gramer's object program. In this case, 
the last statement of the Debug object code 
would specify the address at which Debug | 
is to start executing. When the Debug pro- 
gram has been loaded and initialized, it 
will then notify the programer (via the De- 
bug printout) that it is ready to receive in- 


put commands from the ASR device. 


° If a customer engineer's console is avail- 
able on the PTS-100 being used, the pro- 
gramer may load and start execution of his 
object program, then subsequently interrupt 
execution and initialize the Absolute/Re- 
locating Loader to load and activate the 


Debug program. 


e If the console is not available on the PTS- 
100 being used, the programer may pro- 
gram a transfer of control to the Absolute/ 
Relocating Loader at the point at which De- 
bug is to be loaded. That is, the programer 
may write a source program branch state- 
ment to cause a transfer of control to the 
starting address of the Absolute/Relocating 
Loader, thus setting up the mechanism to 
cause the Loader to read the Debug object 
code at the desired point in the object pro- 


gram. 


In any case, once Debug has indicated that 
it is ready to receive commands, the programer 
may enter the desired Debug input commands 


described in subsection 3.1.1. 


The outputs from Interactive Debug are in 
the form of hexadecimal printouts indicating re- 
sponses to the input commands, as described for : 
those commands that ellicit a Debug keyboard 


printout, and in the form of error messages, de- 


'scribed in subsection 3.2 at the end of this 


section. 


3.1.1 Interactive Debug Input Commands 


There are six kinds of input commands: 


° Keyboard editing commands, which provide 
the programer with the facility to correct 
typographical errors or edit input commands 
before transmitting them to the Debug pro- 


gram, as described in subsection 3.1.1.1. 


8 Memory value access commands, described 


in subsection 3.1.1.2. 


° The program execution control command, 
Go To, which returns control to the execu- 
ting program, as described in subsection 
3.1.1.3. | 


® The address or location computation state- 
ments, Addition and Subtract, described in 


subsection 3.1.1.4. 


e The Proceed command, described in sub- 
section 3,1.1.5, which causes Debug to 
create a new command of the type just 


previous to its occurrence. 


e The breakpoint control commands, Set 
Breakpoint and Clear Breakpoint, described 


in subsection 3.1.1.6. 


In all cases input commands are terminated, 
and therefore transmitted to Debug, by a 
carriage return on the ASR device, or by the 


entry of. 72 consecutive input characters, 


All Debug program input commands must be 
specified in hexadecimal notation (i. e., 16-bit 


unsigned quantities). 


The generalized format of all input com- 


mands is shown below: 


PARAM! FUNCTION CODE PARAM2, PARAM3, PARAM4 


where the command field significance is as 


follows: 

Field 1: PARAMI is the effective address to be 
used by Debug except in the special 
case of the Addition and Subtract 
commands. 

Field 2: FUNCTION CODE is a single character 
indicating the operation Debug is to 
perform. 

Fields 

3-5: PARAMZ2, PARAM3, and PARAM4 are 


unique parameters requesting Debug 


special actions. 


In all cases, input command elements are 
The three 


parameters to the right of the function code must 


written without intervening spaces. 


be separated by commas if they are all present; 
or if the first or second parameter is omitted, 
their omission must be indicated by an extra 
comma, The formats of individual commands 
are diagramed and illustrated in the specific 
detailed descriptions of each command in the 


remainder of this section. 


3.1.1.1 Keyboard Editing Commands. There 
are two editing commands provided: the Cancel 


Record command, and the Logical Backspace 


command. 


36 Leds tect The 


Cancel Record command is used to terminate a 


Cancel Record command ° 
partially completed input command. The com- 
mand is specified by typing a slash (/) charac- 
which is AF in ASCII code. When the slash 
character is typed, Debug expects the first char- 


ter, 


acter of a new command to be entered. Exam- 
ples of the cancel record command are shown 


below. 


Example I: 
Programer input command: 1000D5/1010D 


The programer specified that the entire com- 
mand to the left of the / character was to be re- 
placed by the command following the cancel 
record character. The printout below indicates 
Debug's response to the command: 


Debug response: 1010%*0000 


Example 2: 


Programer input command: 12/0000D 


Debug response: 0000*0A00 


The incorrect command 12 was cancelled and re- 


placed by the command to dump location 0000, 


which was effective, as shown by Debug's re- 


sponse, 


3.1,.1,.1.2 Logical Backspace command (+ ). 


The Logical Backspace command is used to re- 
place the preceding character with the following 
character. The backspace is specified by typing 
the — character, which is the DF in ASCII code. 
When the backspace character is typed, the De- 
bug program replaces the character just preced- 
ing it with the character immediately following 
it, Contiguous preceding characters may be 
replaced by typing contiguous backspace charac- 
ters followed by the replacement characters. 
There are two restrictions on the use of this 


editing command: 


Lee Backspacing is limited to the current field 
being entered. 
2. The backspace command cannot be us ed to | 


override the slash (/) character (i. e., the 


cancel record command), 


Examples of the use of the backspace command 


are presented below. 


Example 1: 


Programer input command: 1000D2- 3 


Changes the count field 2 to 3. Hence the Debug : 


program dumps three locations, starting at 


location 1000, as shown below: 


Debug response: 1000*D900 0826 4283 


Example 2: 


Programer input command: 1000G-D 


Asks that the G function code be changed to D. 


Debug responds by dumping the value in location 


1000, as shown below: 


Debug response: 1000*D900 | 


Example 3: 


Programer input command: 
— Lllle- --0000D 


Changes the entire ADDRESS field from 1's to 


O's, and adds the function code D. 


Debug response: 0000*0A00 


: 3-4 


Example 4: 


Programer input command: 
L00CA- Be Ce De Fe G-AFFF 


Specifies multiple corrections of the function 
code A, with the last correction specifying a 
function code of A and the value OF FF to which 
location 1000 is to be altered, as shown in the 


printout 


Debug response: 1000*000B OFFF 


Soe keZ Memory Value Access Commands, 


These commands direct the Debug program to 
perform the following operations on the values 
stored in the memory locations used by the exe- 


cuting object program: 
e Dump the content of one or more locations. 


© Alter the content of a location with a specific 


value. 


© Fill one or more locations with a specific 


value. 


e Search values in memory locations to find 


a specific value. 


Detailed descriptions of the statements to effect _ 
these operations are presented in the following 


subsections. 


3,.1,1.2.1 Dump command. The Dump com- 
mand is used to specify that a single memory 
word value is to be dumped on the output device, 
or to specify that successive word values are to 
be dumped, beginning at a specific location, as 


shown in the format diagram below. 


FORMAT 


PARAMI PARAM2 
D 


A. or I 


(count > 1) 


If the single word Dump format is used 
(i. e., if no count or a count of 1 is specified), 
Debug prints the specified address and its con- 
tent in hexadecimal notation on the output device, 


as illustrated in the examples below. 


Example lI: 


Programer input command: 0100D 


Debug response: 0100*C204 


Example 2: 


Programer input command: 1000D1 


Debug response: 1000*0281 


The programer may specify that the single- word 
Dump command is to be repeated, as described 
under the Proceed command discussion in sub- 


section 3.1.1.5.1. 


If the multiword Dump format is used 
(i.e., if the count value is greater than 1) Debug 
prints the specified hexadecimal address of the 
first value, followed by a maximum of eight 
hexadecimal values per line on the output device. 
If more than eight values were specified, the 
address and the content of the ninth location are 
printed on the second line, followed by a maxi- 
mum of seven additional memory word values. 
If other lines are required to output the specified 
number of values, the address of the first value 
appears at the beginning of each line, followed 
by successive values from the memory block 
locations, Examples of multiword Dump com- 


mands are presented below: 


SIGNIFICANCE 


Specifies that the content of the memory 


wor 


d located at ADDRESS is to be 


printed on the output device. 


Specifies that the content of a block of 
memory words is to be printed on the 
output device, starting with the value 
stored in ADDRESS. 


325 


Example 1: 


Programer input command: 1000D5 


Debug response: 
1000*C204 AAO02 0300 0806 0108 


Example 2: 


Programer input command: 0100D20 


Debug response: 
0100%*C204 AA0Z 0300 0806 0108 1010 03F3 20A0 
0110*E300 02E3 AA02 0300 07F4 011A 042E 03F8 
0120*9300 0300 C300 02D4 | 


The following three exeptions occur in the 
Debug program's responses to multiword Dump 


commands. 


Exception l 


If the starting address specified as PARAMI 
in the Dump command does not end in zero, 
the location of the next lowest MOD 8 word 
is taken as the starting address of the mem- 
ory block dump, in order to maintain column 
integrity. For example, assume the follow- 
ing Dump command, which specifies that 
four word values are to be dumped, begin- 


ning at location 0106: 

0106D4 
The response of the Debug program is: 
0100*C204 AAOD2 0300 0806 0108 1010 03F3 


where the fourth value from the right (0806) 
is from the programer- specified starting 


address 0106. Hence, the first three values 


were printed as a result of Debug's adjust- the command 

ing the starting address back to the next | | 1000D40 

louiest MOD 6 word location: | | asks that the values stored in 40 consecu- 
_ oo | tive locations are to be dumped, starting at 

Exception 2 oe | | location 1000. The Debug response below 

1000*0281 : 

1020%*0281 0281 1002 1002 0281 0281 0281 0281 

1030*AAAA AAAA 0281 0281 0281 0281 0281 0281 


If all the memory values to be printed on a 
line are identical, only the address and 
value of the starting location are printed. 


F a 3 ' | : : . 
oes mple, assume the Dump command indicates that the first 20 locations contained 


1000D6 | 7 the identical value 0281. Beginning at 
which specifies that the values from six docahonoeney es ros Ora ERE Saemory 
locations are to be dumped, starting at block, unequal values were detected in the 
location 1000. If all six locations contain . i | 
the same value, Debug's response will be: 7 
3.1.1.2.2 Search command. The Search 


epee command directs the Debug program to search 
the values in memory locations, compare them 
Exception 3 — dias : 
oo | to a programer- specified value, and print the 
If all memory values to be printed on sev- addresses and values when equal conditions 
eral successive lines are identical, the out- result from the comparisons, The Search 
_ put lines are suppressed until a line | command may specify a search on a single mem- 
containing an unequal value is detected by ory location, a series-of successive locations, or 
Debug, at which point the location and value a series of successive locations whose stored 
are printed at the beginning of the line, values are masked before the comparison with 
followed by subsequent values to complete the specified value. The permissible formats of 
the line or the dump request. ‘For example, the Search command are diagrammed below: 


FORMAT | 
PARAM1 |FC |PARAM2, PARAM3, PARAM4 ONE Ne 


VALUE A Specifies that the memory word located 

| at ADDRESS is to be compared to 
VALUE and dumped on the output de- 
VALUE, 1 vice if the values are equal. 


or 


VALUE, COUNT Specifies that memory will be searched | 
: starting at ADDRESS, and each word 
will be compared to VALUE and dumped 
if the comparison results are equal. The 
search will terminate after the number 
of words specified by COUNT. 


VALUE, COUNT, MASK | Specifies that memory will be searched 
. starting at ADDRESS, and each word © 
logically ANDed with MASK, the result 
compared to VALUE, and equal values © 
and their addresses dumped. The 
| search will terminate after the number 
| of words specified by COUNT. 


If the single word Search format is used 
(i. e., if no count or a count of 1 is specified), 
Debug compares the programer- specified VALUE 
with the content of the memory address, and if 
the values are equal, prints the address and the 
memory value in hexadecimal notation on the 


output device. 


The programer may specify that the single- 
word search command is to be repeated as de- 
scribed under the Proceed command discussion 


in subsection 3.1.1.5.2. 


When the multiword Search command is 
issued, Debug searches each location from the 
starting ADDRESS through the specified COUNT, 
compares each stored value with VALUE, and 
reports each match via a hexadecimal printout 
of the memory address and value on the output 


device. 


When the MASK parameter is specified in 
the multiword Search command, Debug searches 
each location from the starting address through 
the specified COUNT, logically ANDs each 
stored value with MASK, compares the result 
with VALUE, and reports each match via a hexa- 
decimal printout of the memory address and its 


value on the output device. 


Example 1: 


Programer input command: 1000SF000, 8 


This command specifies that Debug is to search 
eight locations, beginning at location 1000, for 
a stored value of F000 and report a match if it 


is found. 


Debug response: 1008*F000 


The response indicates that Debug found a stored 


value matching VALUE at location 1008. 


Example 2: 


Programer input command: Il1000SFFFF, 8 


< 3-7 


The command specifies that eight locations are 
to be searched, beginning at location 1000, to 
determine if the value FFFF is stored anywhere 
within the memory block. 

Debug response: LOOE*FFFF 


indicates that the value was stored at location © 
100E. 


Example 3: 


Programer input command: 100083, 8 


Asks Debug to search eight locations, starting 
A line feed 


without an accompanying printout indicates that 


with location 1000, for the value 3. 


the value 3 was not stored within the eight 


locations specified for searching. 


Example 4: 


Programer input command: 
100088000, 8, 8000 


Asks Debug to search eight memory locations, 
starting at location 1000, mask their contents, 
compare the results of the AND mask with 8000 


to determine if the most significant bit (MSB) is 


set. Assume the following response from the 


Debug program: 


1008*F000 100A*FF00 100C*FFFO 100E*FFFF 


A match is found at locations 1008, 100A, 100C, 
and 100E., 


Example 5: 


Programer input command: 1000S1, 8, 000F 
Asks Debug to search eight memory locations, 
starting at location 1000, mask their stored 
values withO00OF, and report any matched values 
whencomparedtol, The search operation is totest 
for addresses whose contents have their LSB and 


not bits 12, 13,14 set. The Debug printout 


1006*0001 


indicates that a matchwas found at location 1006, 


3.1.1.2.3 Alter command, The Alter com- 
mand directs the Debug program to alter, or 

replace, the memory word value ina specific 

location with the value specified in the command, 


the format of Ghiek is shown below. 


FORMAT 
-| PARAM 1 PARAM 2] 


SIGNIFICANCE 


Specifies that the 
content of the mem- 
ory location indica- 
ted by ADDRESS is 
to be replaced by 
the VALUE in 
parameter, of the 
command. ~ 


ADDRESS VALUE 


When the command is processed by the 


Debug program, the specified VALUE replaces 
the original content of the ADDRESSed location. 
The ADDRESS, the original value stored there, 
and the new value are printed in hexadecimal 


notation on the output device. 


The programer may specify that the Alter 
command is to be repeated for the next consecu- 
tive location(s), as described under the Proceed 
command discussion in subsection 3.1.1.5. 1. 
To alter or fill blocks of memory locations with 
new values, the programer should use the Fill 


command described below. 


3.1.1.2.4 Fill command. The Fill command 
directs the Debug program to fill one or more 
memory locations with a specific value, as 


shown in the format diagram below: 


FORMAT 


If the single word Fill command format is 
used (i, e., if no count or a count of 1 is speci- 
fied) the Debug program fills the ADDRESSed 
location with the specified VALUE. 

Under Interactive Debug, the programer _ 
may specify that the single word Fill command 
is to be repeated for the next consecutive loca- 
tion{s), as described under the Proceed com- 

If the 


multiword Fill format is used, the Debug pro- 


mand discussion in subsection 3.1.1.5.1. 


gram fills each location from the starting 
ADDRESS through the COUNT with the specified 
VALUE, 


Neither format of the Fill command causes 
If the 


programer wishes to verify that the Fill opera- 


printed output at the interactive device. 


tion is successful, he should dump the pertinent 
memory locations before and after issuing the 


Fill command. 


3.1.1.3 Go To Command This command 


directs the Debug program to transfer control 


toa specific address in the object program, 
and start object program execution at that 
address, The permissible formats of 

the Go To command are presented in 

Table 3-2. 


As shown in table 3- 2, the Go To command 
may optionally specify that new values are to be 
loaded into any one, two or all three of the 
following registers: accumulator, index regis- 
ter 1, and index register 2, If values are to be 
loaded into the respective registers, they must 
be specified in the appropriate order: AC value, 


X1 value, and X2 value. If either the AC value 


SIGNIFICANCE 


ADDRESS 


ADDRESS 


IPARAM1 | FC | PARAM2, PARAM3 


VALUE A or 
VALUE, 1 


| Specifies that the ADDRESSed location 
is to be filled with VALUE 


Specifies that successive Memory lo- 
cations, specified by COUNT, are to 
be filled with VALUE. ADDRESS 
specifies the first, or starting, lo- 
cation of the memory block. 


VALUE, COUNT 


Table 3-2. Permissible Formats for Go To Command 


FORMAT 


FC |PARAM2, PARAM3, PARAM4 SIGNIFICANCE 


ADDRESS |G 


PARAM 1 


Specifies that Debug is to 
transfer control to ADDRESS 
in the object program and 

start its execution. 


ADDRESS | G ACVAL, X1VAL, X2VAL Directs Debug to load speci- 
. fied VALS in the AC, XI1, and 
X2 and transfer control to 
and start execution of the 


object program at ADDRESS. 


Directs Debug to load speci- 
fied VAL in AC, leave Xl 
and X2 unmodified, and start 
object program execution at 
ADDRESS. 


ACVAL, XIVAL Directs Debug to load speci- 
fied VALs in AC & XI, leave 
X2 unmodified, and start 


execution at ADDRESS. 


ACVAL, ,X2VAL Directs Debug to load speci- 
fied VALs in AC & X2, leave 
Xl unmodified, and start 


execution at ADDRESS. 


»XIVAL, X2VAL Directs Debug to load speci- 
. fied VALs in X1 & X2, leave 
AC unmodified, and start 


execution at ADDRESS. 


Directs Debug to load speci- 
fied VAL in X11, leave AC and 
X2 unmodified, and start 
execution at ADDRESS. 


Directs Debug to load X2 with 
specified VAL, leave AC & 
Xl unmodified, and start 

execution at ADDRESS. 


or the X1 value or both values are unspecified, Example 1: 


their respective omission must be indicated by a 
comma, That is, Debug assumes that the first | ; 

3 Programer input command: 1000Gl1,,1 
value following the G function code is to be loaded | 


into the accumulator, the second in index regis- 


ter 1, and the third in index register 2. Twoor Debug reponse: loads AC with the value Ls 
more values must be separated by commas. leaves X1 unmodified (specified by the second 
Trailing commas are not required for unspecified comma), loads X2 with the value 1, transfers 
values. Examples of Go To commands are pre- control to location 1000 in the object program, 
sented below. and starts its execution. 


Example 2: 


Programer input command: 1010G,1,2 


Debug response: loads X1 with the value l, 
X2 with the value 2, leaves AC unmodified, and 
starts execution of the object program at loca- 
tion 1010. | 


Example 3: 


Programer input command: 1000G,,2 


Debug response: loads X2 with the value 2, 
leaves both AC and X1 unmodified, and starts 


object program execution at location 1000. 


Example 4: 


Programer input command: 1000G, 3 


Debug response: loads X1 with the value 3, 
leaves AC and X2 unmodified, and starts object 


program exeuction at location 1000. 


Example 5: 


Programer input command: 1000G6 


Debug response: loads AC with the value 6, 
leaves Xl and X2 unmodified, and starts pro- 


gram execution at location 1000. 


Example 6: 


Programer input command: 1000G 


Debug response: transfers control and 
starts execution of the object program with AC, 


X1, and X2 containing their original values. | 


3.1.1.4 Address Computation Commands. To 
aid in on-line testing and checkout of object pro- 


grams, the capability to add or subtract two 
hexadecimal constants and output the result has 
been provided via the Addition and Subtract 
commands. These statements assist the pro- 
gramer in computing absolute locations in re- 


locatable programs, or in computing the absolute 


| CONI1 + | 


location of a data word based on a program 
counter relative instruction referencing that data 
word. The following pages present detailed de- 
scriptions of the use of the Addition and Subtract 


commands, 


3.1.1.4.1 Addition command. The Addition 
command specifies that the Interactive Debug 
program is to add one hexadecimal constant to 
another, as shown in the format diagram below. 
The constants may be from one to four digits in 
length. Leading zeros need not be written in 
constants less than four digits long. 


FORMAT 


PARAM] PARAM 2 


CON2 


SIGNIFICANCE 


Directs Debug to add 
the left constant to 
the right constant. 


NOTE 


The Addition code is the plus 
(+) sign, which is the shifted 
semicolon on the ASR device. 


When the Addition command is issued, the | 


- Debug program adds the first constant (CON1) to 


the second constant (CON2) and reports the re- 
sults preceded by an equal (=) sign, as illustrated 


below. 
Example 1: 
Programer input command: 100041 


Debug response: =1001 


Example 2: 


Programer input command: 1000+1234 
Debug response: =2234 

Example 3: 

Programer input command: 1+t1 


Debug response: =0002 


3: 3-10 


Example 4: 


Programer input command: 800041 


Debug response: =8001 


Example 5: 


Programer input command: FFFF+tl 
Debug response: =0000 
Example 6: 
Programer input command: 7FFFtl 
Debug response: =8000 
Example 7: 
Programer input command: 100+1000 
Debug response: =1100 
Example 8: 
Programer input command: ABCDtF 
Debug response: =ABDC 
Example 9: 
Programer input command: FFFFtFFFF 
Debug response: =FFFE 
The Proceed command (subsection 
3, 1.1.5.3) may be used following an Addition 
command to supply different CON2's to be added 


to the original CONI, and thus perform other 


Addition computations. 


3.1.1.4.2 Subtract command. The Subtract 
command specifies that the Interactive Debug 
program is to subtract one hexadecimal con- 


stant from another, as-shown in the format 


Eee ee Ii 


CON] 


diagram below. The constants may be from one 


to four digits in length. Leading zeros need not 


be written in constants less than four digits long. 


FORMAT 
PARAM2 


CON2 


PARAMI 


SIGNIFICANCE 


Directs Debug to 
subtract the right 
constant from the 
left constant. 


When the Subtract command is issued, the 


Debug program subtracts the second constant 
(CONZ2) from the first constant (CON1I) and re- 
ports the results, preceded by an equal (=) sign, 


as illustrated below. 
Example 1: 
Pro gramer input 
Debug response: 
Example 2: 
Programer input 
Debug response: 
Example 3: 
Programer input 
Debug response: 


Example 4: 


Programer input 


Debug response: 


Example 5: 


command: 


=FFFF 


command: 


=0000 


command: 


=0001 


command: 


=FFFE 


FFFF- 1 


Programer input command: FFFF-FFF 


Debug response: 


=F000 


Example 6: 


Programer input command: 8000-1 


Debug response: =7FFF (overflow condition) 


Example 7: 
Programer input command: FFFF-7FFF 


Debug response: =8000 


Example 8: 


Programer input command: 0-CA 


Debug response: =FF36 


Example 9: 
Programer input command: ABCD-AAAA 


Debug response: =0123 


The Proceed command, described below, 
may be used following a Subtract command to 
supply different CON2's to be subtracted from 
the original CONI and thus perform other Sub- 


tract computations. 


3.1.1.5 Proceed Command. The Proceed 
command specifies that the Debug program is to 
refer to the input command just preceding it 
(i.e., the most recent command specifying a 
command code other than P) and create a new 
command of the same type with different param- 
eters to the right of the function code. That is, 
the previous effective address and function code 
are used with the new parameters. The format 
of the Proceed command depends, of course, on 
the particular Debug input command it immedi- 
ately follows, as shown in the following sub- 
sections. The Proceed command is not effective 
after a Set Breakpoint or Clear Breakpoint com- 


mand. 


3.1.1.5.1 Proceed command use after Alter, 

Dump, and Fill commands. After execution of a 
single word Alter, Dump, or Fill command, the 
Debug program increments the ADDRESS speci- 


fied in the command by 2 and saves it. If the 


next sequential command is a Proceed (i.e., be- 


gins with function code P), the Debug program 


performs an Alter, Dump, or Fill operation, as 


| specified by the new parameter(s) following the 


P function code, as shown in table 3-3 and 
illustrated in the examples at the end of this 


subsection, 


Example 1: 
Assume that the most recent Debug input 


command is an Alter command: l0O0O0AFOFO 


The Proceed command below 
PFFFF 


tells Debug to fill location 1002 (i.e., the saved 
Alter ADDRESS+2) with the value FFFF. 


Example 2: 


Assume that a second Proceed command 
follows the one in Example 1, which specifies 


the following: PAAAA 


The command specifies that Debug is to fill the 
location following 1002+2 (i, e., 1004) with the 
value AAAA, | 


Example 3: 


Assume that the most recent Debug input 


command is the Dump command 
0100D 
after which the Proceed command 
#P 


causes location 0102 (Dump ADDRESS+#2) to be 
dumped, as follows: 0102%*AA02 


Se. See 


Table 3-3. Effect of Proceed Command After Alter, Dump or Fill: Commands 


. PROCEED COMMAND 
PREVIOUS FOR Krerenesrres 


COMMAND Lee | PARAM], | PARAM1, PARAM | SIGNIFICANCE 


ALTER VALUE! First Proceed command causes 
VALUE1 to be stored in ADDRESS+#2, 
which was saved after preceding 
ALTER command execution, and a 
printout of ADDRESS+2, the original 
value and the new value to be printed 
out. 


VALUEZ2 Second Proceed command causes 
ADDRESS+2 to be incremented by 2, 
VALUEZ2 to be stored in ADDRESS#4, 
and a printout of ADDRESS#4 and its 
original and new value. 


A or l The first Proceed following DUMP 
causes a dump of the stored value in 
ADDRESS+2, which was saved after 
the Dump command execution, 


A or 1 Second Proceed causes ADDRESS#2 
to be incremented by 2 and the stored 


value of ADDRESS+4 to be dumped. 


Causes the ADDRESS#2 saved after 
Dump execution to be used as the 

| starting address and to be sequentially 
incremented to dump the number of 
consecutive locations specified by count. 
The starting location and stored values 
in the block of locations are dumped. 


(count > 1) 


FILL VALUE laAor The first Proceed following FILL 
VALUEI, 1 causes VALUE] to be stored in 
| ADDRESS+2, which was saved after 
Fill command execution. 
VALUEZ2A or Second Proceed command causes 
VALUEZ2, 1 ADDRESS +2 to be incremented and 
VALUEZ2 to be stored in ADDRESS1H4. 

P VALUE, (count>1)/ Causes the ADDRESS+#2 saved after FILL 
execution to be used as the starting ad- 
dress and to be sequentially incremented 
to fill the number of consecutive locations 

| specified by count with VALUE. 
NOTE 
All addressing is in bytes. 

Assume that the programer now wants to In the same manner, the programer can dump 
dump the value in the next location, which can the next two locations by issuing the Proceed 
be effected by the P command command 

, P2 
Pp 


which causes Debug to begin the dump at the 

original Dump address 0100, as shown by the 

which causes the Debug response : 
printout 


0104*0300 0100*C204 AAO02 0300 0806 0108 


36 3415 


Example 4: 


Assuming that the most recent Debug input 


command is the Dump command 
0100D 


the ten locations starting at 0100 can be dumped 


by issuing the Proceed command | 
PA 
The dump is as follows: 


0100*C204 AAOZ 0300 0806 0108 1010 03F3 20A0 
0110%E300 02E3 AAO2 | 


Example 5: 


Assuming that the most recent input com- 


mand is the Fill command 
1000 F9999° 


The following Proceed commands illustrate a 


method of program patching: 


fills locations 1002 and 
1004 with the value 1234 


1002F1234, 2 


P4321 fills location 1004 with 
the value 4321 
PABCD #ils 1écdbow 1006 with 
the value ABCD 
PFFFF, 8 fills location 1008 through | 


1016 with FF FF 


3.1.1,5.2 Proceed command use after Go To 
and Search commands. When a Go To or 
Search command is executed by Debug, the exe- 
cution ADDRESS is saved. If the next sequen- 
tial command is a Proceed (i.e., begins with a 
P function code) the Debug program uses the 
saved address to create a new command with the 
new values specified to the right of the P func- 


tion code, as shown in table 3-4, 


The Proceed command may be used to 
create a new Go To command only when both of 


the following conditions exist: 


e The object program has received control 
from Debug as the result of a programer- 


issued Go To command, 


° Control has subsequently been returned to 
Debug because the object program encoun- 


tered a breakpoint address. 


If the above conditions are met, the pro- 
gramer may issue a Proceed command to cause 
control to be returned to the ADDRESS specified 
in the original Go To command just preceding 
the return of control to Debug. The Proceed 
command may optionally specify one or more 
new values to be loaded into the accumulator, 
X1, and/or X2. If no new values are specified, 
the transfer from Debug to the object program 


takes place without modification of the registers, 


If a Proceed command follows a Search 
command (function code S) the starting address 
of the search operation will be the same as in 
the original Search command, but new values 


must be entered following the P code. 


3.1.1.5.3 Proceed command use after 


Addition and Subtract commands, When the 


Interactive Debug program is being used, the 
Proceed command may be used following the 
Addition or Subtract command by merely enter- 
ing the P function code followed immediately by 
a new CON2 value. That is, when an Addition 
or Subtract command is executed by Interactive 
Debug, the CONI value to the left of the + or - 
function code is saved. Hence, if the next se- 
quential command is a P command, Debug 
performs the specified operation using the 
original CONI1 value and the new CON2 value 
specified in the Proceed command. The format, 
then, for the Proceed command following an 


Addition or Subtract command is: 


PCONZ 
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PREVIOUS 
COMMAND 


_ ei 


| SEARCH 


Table 3-4. Effect of Proceed Command After Go To or Search Commands 


| PROCEED GOMMAND FORMAT 


PARAM1, PARAM2, PARAM3 | SIGNIFICANCE 


Specifies that Debug is to transfer control to 
the original Go To ADDRESS and start pro- 
gram execution without modifying any registers. 


ACVAL, XIVAL, X2VAL Specifies that Debug is to load new values in 
the AC, X1, and X2 and start object program 
execution at the ADDRESS specified in original 


Go To command. 


ACVAL Directs Debug to modify the current value in 
the AC with the new value and return control to 
ADDRESS specified in preceding Go To command. . 


ACVAL, XIVAL Directs Debug to load specified VALues in the 
AC and X1, leave X2 unmodified, and start pro- 
gram execution at original Go To ADDRESS. 


Directs Debug to modify AC and X2 with new 
VALues, and return control to ADDRESS 
specified in preceding Go To command. 


ACVAL, , X2VAL 


Directs Debug to load X1 & X2 with new 
VALues, leave AC unmodified, and return con- 
trol to preceding Go To ADDRESS. 


,X1VAL, X2VAL 


Directs Debug to load X1VAL in X1, leave AC |. 
and X2 unmodified, and return control to 
ADDRESS specified in original Go To. 


Directs Debug to load X2 with the specified 
X2VAL, leave AC and X1 unmodified, and 
return control to original ADDRESS specified 
in preceding Go To command. 


VALUEA 


or 


VALUE] 


Specifies that Debug is to search the memory | 

word located at the ADDRESS originally 

specified in preceding Search command, 

| compare its content with VALUE, and print 
the ADDRESS and value if an equal condition 
is met. 


VALUE, COUNT Specifies that the memory locations specified 
‘by COUNT are to be searched, starting at 
ADDRESS specified in preceding Search 
command, compared to VALUE, and any equal 


values are to be reported onthe output device. 


Specifies that Debug is to search the memory 
locations specified by COUNT, starting at the 
ADDRESS specified in the preceding Search 
command, logically AND each stored value 
with MASK, compare the results with VALUE, 
and report equal values and their address via 
a printout onthe output device. 


VALUE,COUNT, MASK 
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Following are examples of Proceed command 


use and the results obtained. 


Example 1: 

Proceed following Addition command 
Programer input command: 1000+I 
Debug response: =1001 
Programer input command: P2 
Debug response: =1002 
Programer input command: PFF 


Debug response: =l0FF 


Example 2: 


Proceed following Subtract command 
Programer input command: 0-1 
Debug response: =FFFF 
Programer input command: Pz 
Debug response: =FFFE 
Programer input command: PF 


Debug response: =FFFI1 


3.1.1.6 Breakpoint Control Commands. The 
breakpoint control commands are Set Break- 


point and Clear Breakpoint. 


3.1.1.6.1 Set Breakpoint command. This 
command is used to set from one to four break- 


point addresses within the object program. The 


Set Breakpoint command format is shown below. 


| FORMAT 
PARAMI 


SIGNIFICANCE 


a breakpoint is to be set in the 
object program. 


ADDRESS L Specifies the address at which 


There are two restrictions on the use of the 


Set Breakpoint command: 


® No more than four breakpoints may be in 
effect at a given time in the executing 


program. 
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FORMAT 
aul 


ADDRESS C 


@ Breakpoint addresses must not specify the 


second word of a two word (long format) 


executable instruction. 


When a Set Breakpoint command is issued, 


the Debug program performs all of the following: 


° Saves a 5-word block of code in the object 
program, beginning at the specified 
ADDRESS. 


@¢ Overlays the saved object program code 
area with a 5-word Breakpoint Transfer 
Block (BTB) to effect a transfer of control 
to Debug when the breakpoint address is 


encountered in the object program. 


Waits for the next programer input com- 


mand. 


When a breakpoint address is encountered 
in the executing program, control transfers to 


the Debug program which performs the following: 


o Prints the breakpoint address, and the 


current values of the accumulator, Xl, and 
X2. 


e Waits for the next programer input com- 


mand. 


In all cases, to return to the object program, the 


programer must issue a Go To command. 


3.1,1.6.2 Clear Breakpoint command. The 
Clear Breakpoint command, formated below, 


clears a breakpoint previously set by the Set 


Breakpoint command. 


SIGNIFICANCE 


Specifies that the breakpoint 
previously set at ADDRESS 
is to be cleared. 


When a Clear Breakpoint command is 
issued, the Debug program clears the break- 
point set for the specified address, restores the 
saved object program's code in the area 
currently occupied by the BTB associated with 
the breakpoint, and waits for the next input 
command. To return to the object program, 


the programmer must issue a Go To command. 


3.2 Debug Output Error Mes sages 


When an error in processing or data entry 
is detected by Debug a two character error 
message is logged on the list device. Debug's 
recovery procedure is to terminate processing 
the current input command, log the error code 
on the ASR device, issue a line feed and carriage 
return, and initiate input of another input com- 
mand. No data from erroneous input commands 
is saved. The user may reenter that command 
correctly, or enter any other valid input com- 
mand. Tne error codes and their signficance 


are shown in table 3-5, 


Table 3-5. 


Message 
Code 
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Interactive Debug Error Messages 


Meaning 


Input buffer full; more than 72 
characters in input record. 


Clear Breakpoint command given 
for ADDRESS not currently in 
breakpoint stack. 


Function Code or Field Delimiter 
omitted from input record. 


Non- Hex number found in Hex 
Data Field. 


Parameter | omitted from a com- 
mand requiring it be supplied. 


Parameter 2 omitted from a com- 
mand requiring it be supplied. 


Parameter 3 omitted from a com- 
mand requiring it be supplied. 


System Error - reload or mainte- 
nance required. 


System Error - reload or mainte- 
nance required. 


Least significant bit set in para- 
meter 1, indicating effective 
address on a non-word boundary. 


Set Breakpoint command issued 
after the maximum number have 
been stored in the breakpoint save 
stack. 


Section 4. 


The System Generator (SYSGEN) program 
provides for the generation of a specially-tailored 
PTS-100 1OCS monitor to meet unique applications 
processing requirements. Thatis, for any given 
PTS-100 installation, a specialized lIOCS monitor 
can be generated by describing its content to the 
SYSGEN program. The system descriptions are 
supplied on key word directive cards, which are 
inputto the SYSGEN program. There are six key 
word directives: TITLE, ACIC, ASGL, ASCP, 
CALL, and END. These directives are described 
individually in the subsections immediately 


following. 
4.1 Command Directives 


The inputs to SYSGEN are command directives 
containing key words and the parameters neces- 
sary to describe the system to be generated. 


Input on punched cards, the six directives are: 


@ One TITLE directive, which is used to assign 
a name to the system being created, and to 
specify PTS-100 Assembler file assignments 


and assembly options. 


e One optional ACIC directive, which is used 
only when a channel interface controller 
(CIC) is attached to the object PTS-100. The 
ACIC directive specifies the number of de- 
vices to be attached to the CIC, the tumble 
table to be used, the base device address, 
and the channel address of each group of 16 


devices attached to the CIC. 


e One ASGL directive, which is used to assign 
physical I/O devices to logical units whose 


names appear in lOCS tables. 


e One or more ASGP directives, which are 
used to assign hardware addresses to physi- 
cal I/O devices, and to specify the interrupt 


levels to which the devices are to be assigned. 


SYSTEM GENERATOR PROGRAM 


e One or more CALL* directives, which are 

| used to insert macro calls to effect spe- 
cialized IOCS monitor routine creation by the 
PTS-100 Assembler when the generated sys- 


tem is assembled. 


@ One END directive, which terminates the 


input directive processing. 


Within the input card deck, the directives 
must appear in the order in which they are listed 
Except for the ASGP and CALL directives, 


only one directive of a given type may appear in 


above. 


the input deck. The specifications for writing the 
individual directives and their parameters are 
described and illustrated in the following sub- 
sections. 
4.1.1 TITLE Directive 

One TITLE directive is used to establish the 
information the PTS-100 Assembler requires for 
its options record when a given generated system 
is assembled. The directive specifies three types 


of information: 


e The system name, which must be specified. 


The name is eight characters in length. 


° The file (i.e. , device) assignments for those 
devices to be used by the Assembler, if other 
than default device assignments are to be 


used (see Section 5 of Part 2 of this handbook), 


e The assembly options desired. 


The TITLE directive format is illustrated in 
figure 3-3. 


*The CALL directive permits users to call 
their own generalized IOCS monitor macro 
routines, defined to satisfy applications- unique 
requirements such as nonstandard device driving 
and servicing routines. ahe source code of call- 
ed routines must have been stored on the System | 
Macro Library file to be used as input to the 
Assembler. 


TITLE =, {10CS nam Op! , Op2 , Op3 , Op4 , Op5 , Opé 


: | | HN 


Figure 3-3. Format of the TITLE Directive 


The content of the individual fields of the 4.1.2 ACIC Directive 
TITLE directive is presented below. 


Field 1: TITLE must appear in columns 1-5, 


One ACIC directive is used when, and only 


when, the channel interface controller (CIC) is to 


followed by a comma in column 6 


be used on the PTS-100 for which a given IOCS 


monitor is being generated. When used, the 


Field 2: The system name must appear in ACIC directive must follow the TITLE directive 
columns 7 - 14, followed by a comma in the SYSGEN input deck. It specifies the 


in column 15. 


information needed by the IOCS monitor to support 
the CIC and its attached devices. The ACIC 


Fields 3-8: Assembler options (Opl through directive is written in the format 


Op6) may be specified as shown below. 


OPTION 


ACIC,nn, T, BDA, CAD., CAD.,CAD.,CAD 
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SELECTION TITLE CARD 


Column 


Ovl Cross reference listing ] 34 
P No cross reference listing (default) | A 
Ov? Sequence checking ] 36 
P No sequence checking (default) | A 
On3 Macros included 3 A 38 
P No macros included (default) 1 
Ov4 Relocatable object text (default) A 40 
P Absolute object text : 1 
Full listing, macros expanded (default) | A | 42 
Full listing, macros not expanded 1 
Ops Error listing only 2 
No listing 3 | 
sade - Machine language produced (default ) A 44 
P No machine language produced i] : 


where: 


nn specifies the total number of devices 
attached to the CIC, and must be one of the 
following: 16, 32, 48, or 64. 


T specifies the tumble table to be used. 


BDA specifies the base device address to 


be used. 


CAD) 


one of which must be specified for each group 


of 16 devices attached to the CIC. 


- CAD, specifies channel addresses, 


A minimum of one and a maximum of four 
groups of devices may be attached to the CIC. 
That is, the number of groups attached and the 
CADs required relates to the nn specification 


as shown below: 


Number of | Channel Address(es) (CADs) 
jnn Groups Required 
CAD 


] 
CAD, » CAD 


2 
CAD, , CAD,, CAD 
CAD, , CAD 


3 


CAD,, CAD 


2’ 4 


As shown above, unnecessary CADs in the ACIC 


directive may be left blank. 


If, however, more than one group of devices 
is to be attached to a given channel, the channel 
address must be specified once for each group | 


attached. For example, the directive 
ACIC, 64,1, F40, F80, F80, F80, F80 


specifies that all 64 devices (i.e., four groups) 


are to be attached to channel address F80. 
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4.1.3 ASGL Directive 


For a given system, one ASGL directive is 
used to specify the assignment of physical I/O 
devices to the logical units whose pointers appear 
in the lOCS input/output control table (IOCT). The 
directive contains ASGL in columns 1 - 4 of the 
input card, followed by the physical device nota- 
tations to be used an assignments to logical units 
in the IOCT. The device notations are separated 
by commas, and are written in the format illus- 


trated below: 


ASGL, D1, D2, D3, D4,D5, D6, D7, D8, D9, D10, D11, D12,D13 


where ASGL must appear in columns | - 4 follow- 
ed by a comma in column 5, and the Ds are de- 
vice notations which have the following significance 


in the order in which they appear: 


D1 device assigned for SYSF (System File) 

D2 device assigned for SYSI (System Input 
Device) | 

D3 device assigned for SYSL (System Logging 
Device) 

D4 device assigned for SYSD (System Data 
Device) . 

D5 device assigned for SYSB (Binary Output) 

D6 device assigned for SYST (System Listing 
Device) 

D7 device assigned for SYSO (System Output 
Device) 

D8 device assigned for SYSR (System Scratch 
Device) 

D9 device assigned for LOG8 (Logical Unit 8) 

D10 device assigned for LOG9 (Logical Unit 9) 

Dll device assigned for LOGA (Logical Unit A) 

Dl2 device assigned for LOGB (Logical Unit B) 

D13 device assigned for LOGC (Logical Unit C) 


NOTE 


If a device is not to be assigned, 

the omission of its notation must 
be indicated by a series of three 
zeros. 


The device notations that are permissible for 


various device assignments are shown in table 3-6. 


Table 3-6. Device Notations for Use as SYSGEN 
Directives 
Notation Associated Device 
AMn Asynchronous Modem 
CAn Cassette Unit 
CIn Channel Interface Controller 
CMn Card Reader Multiplexed 
CPn Card Punch 
CRn Card Reader 
DKn Disc Unit 
DR Display Keyboard Receive 
FPn High Speed Paper Tape Punch 
FRn High Speed Paper Tape Reader 
KRn ASR Keyboard Receive 
KSn ASR Keyboard Send 
LP Line Printer 
MHn Modem Half Duplex (synchronous) 
MMn Modem Multiplexed 
MRn Modem Receive (PARS) 
MSn Modem Send (PARS) 
PMn Printer Multiplexed 
SRn Special Display Keyboard Receive 
SPn Serial Printer 
TPn Magnetic Tape Unit 


NOTE. 


nis a decimal integer to specify 

a particular device where multiple 
devices of the same type appear in 
the equipment configuration. 


4.1.4 ASGP Directive 


This directive is used to specify the identi- 
fication, hardware address, interrupt level, and 
macro processor special code for each physical 
I/O device to be used by the system being gen- 
erated. The parameters specified on ASGP 
directive cards are used to complete the IOCT, 
started with the ASGL directive parameters, to 


build other tables (é.g., the PIOT), in the IOCS 


monitor, and to specialize the interrupt packets, 
level service routines, and the driver and service 
routines for each assigned device. The ASGP 


directive format is as follows: 


ASGP, D, ID, DAD, DIL, DSC, D,IM,SEN,..., 


D ID,D_AD,D IL,D SC,D IM,SEN 
n n n n n 


The ASGP key word must appear in card columns 
1 - 4, followed by a comma in column 5, which is 
followed by a string of parameters, separated by 
commas. The parameter strings are composed 


of sets of parameters, with six parameters ina 


precise order required in any given set, as follows: 


DID, DAD, DIL, DSC, DIM, SEN 


where: 


DID is one of the following: 
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the device identifier, specified as the appro- 
priate notation from table 3-6, when only one 
device of this type is attached to a multi- 


plex controller, or 


a comma, indicating that multiple devices of 
this type are attached to the same multiplex 
controller, as specified by the DIM para- 


meter in position 5 of the parameter list. 


DAD is the device hardware address assigned to 
the device identified by DID or DIM. 


DIL is the external interrupt priority level (level 
1 through 8, as shown in table 3-7) to which the 


device is to be assigned. 


DSC is a two character code which may be used 
to effect further specialization of the particular 
device's interrupt handling, service, and driver 
routines by the macro processor of the PTS-100 


Assembler. 


Table 3-7. Interrupt Priority Levels 


in the PTS-100 


Interrupt 
Level Interrupt Type 


[9 [trp 
a 
[6 fieternal 6 
nm 


Device 
Interrupt 
Levels 


Processor/Interval 
Timer 


DIM is one of the following: 


the device identifier, specified as the appro- 
priate multiplexed identifier notation from 
table 3-6, when more than one device of the 
same type is attached to the same multiplex 
controller, or | 

a comma if only one device of this type is 


attached to a given multiplex controller. 


SEN is a sentinel, which must be one of the follow- 


ing: 


an L to indicate the last device 
type that is attached to the same multiplex 


controller, or 


a comma if DID is specified in the parameter 
list or if this is not the last device of an 
identical type attached to the same multi- 


plex controller. 


A special code is used in the generalized 
#IMLSR macro routine in the #IMPIT macro 
routine that creates PIOTs for each I/O device. 
That is, the parameters within each set in the 


ASGP directive become actual arguments in the 


call to the #IMLSR and other macro routines. 
The special code may be any two character value 
the programer wishes to use, but must be dif- 
ferent in each parameter set. It must be specified 
as the fourth parameter in each set of parameters 


for a specific device. 


‘Ihe DID and DIM parameters should not both 
That is, DID 


specifies that only one device of this type is 


appear in the same parameter set. 


attached to a given multiplex controller, and will 
cause a unique set of device handling routines to 
The DIM para- 


meter specifies that more than one device of this 


be created in the LOCS monitor. 


type is attached to a given multiplex controller, 
and will cause a common set of device handling 
routines for this type of device to be created in 


the LOCS monitor. 


Any number of ASGP directives may appear 
in succession in the input deck. Each directive 


begins with ASGP, followed by a set of parameters. 


To illustrate the use of the ASGP directive, 


assume the following two cards: 


ASGP, CR1, 01A, 3, 00,,, 
ASGP, CA1, 025, 1, 0X,,, 


The first set of parameters specifies the following: 


CR1l is the identitier for card reader device l 


01A is the hardware address to be assigned 
to card reader 1 


3 is the external interrupt priority level to 
which card reader 1 is to be assigned 


00 is the default special code 


NOTE 


Since the device identifier is speci- 
fied in position 1 of the parameter 
set, the DIM and SEN parameters in 
positions 5 and 6 are omitted, as in- 
dicated by commas inthese positions. 


The second set of parameters specifies the following: 


CA1 is the identifier for cassette unit l 


025 is the hardware address to be assigned to 
cassette unit 1 


1 is the external interrupt priority level to 
which cassette unit 1 is to be assigned 


OX is a special code to be used by the Assem- 
bler in specializing the IOCS routines 


The omission of the DIM and SEN parameters is | 
indicated by commas in their positions in the 


parameter set. 


The following example illustrates the four 
ASGP directive cards necessary to specify four 


multiplexed serial printers: 


ASGP, PM1,018,2, 00,,, 
ASGP, ,0C0,2,00, PMI,, 
ASGP,,010,2,00, PM1,, 
ASGP,,014,2,00, PMI, L 


The parameters on the first card specify the 


following: 


PM 1 is the identifier for the first serial 
printer to be multiplexed. 


018 is the hardware address to be assigned 
to the first serial printer. 


2 is the external interrupt priority level to 
which the first serial printer is to beassigned. 


00 is the default special code. 


Positions 5 and 6 are omitted (see Note on 
previous page). 


The parameters on the second card specify: 


The comma in position 1 indicates that multi- 
ple printers are attached to the same printer 
driver and service routine as specified in 
position l of card l. 


The next three positions are the same as on 
card 1, except for changes in the parameter 
values. 


PM1 is the identifier for the device that is 
being multiplexed. 


Card 3 is similar to card 2, with the parameter 
values changed. Card 4is also similar except 

that position 6 contains an L to signify that this 

is the last device of this type. 


As many as 22 sets of parameters may be 


specified for a given system generation. That is, 
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a maximum of 22 devices may be entered into a 


system to be generated by SYSGEN. 


4.1.5 CALL Directive 

CALL directives effect the generation of | 
macro routine call statements to cause the PTS- 
100 Assembler to create specialized macro 
routines from user-defined generalized macro 
routines, according to the arguments specified 
in the CALL directives. The format of the CALL 


directive is shown below. 


CALL, A$AmacronamjArgument,,...Ar gument | 


ae 


The key word CALL must appear in card columns 
1 - 4, followed by a comma in column 5, a space 
in column 6, a $ in column 7, and a space (i.e., 

blank character) in column 8. The macro routine 
name, up to 8 characters in length, starts in 

The 
The 


name must be that of a generalized macro routine 


column 9 and may range through column 16. 


name is terminated by a blank character. 


on the System Macro Library file that is input to 


the Assembler run. 


Following the blank character terminating 
the macro routine name is the actual argument 
list (i.e., one or more actual arguments, 
separated by commas) that the Assembler is to 
use to specialize a routine for the monitor being 
generated. For a detailed description of macro 
aGdtine definiaon, nee Section 4 5 Part 2 of this 
handbook. 


Any number of CALL directives may appear 
in the deck. Each card is written in the format 


shown above. 


4.1.6 END Directive 


The END directive terminates the input 
directive file processing by SYSGEN. It must, 
therefore, be the last card in the input deck. The 
END directive key word appears in columns 1 - 3 
of the last input card. No other columns are used 


on this card. 


4.2 SYSGEN Processing 


SYSGEN generates the necessary call state-. 
ments to effect the creation of a specially-tailored 
IOCS monitor according to the key word directives 
and their parameters as described above. The 
output of SYSGEN is a file, in PTS-100 Assembler 
format, composed of an Assembler options 
record and the macro calls to the generalized 
System Macro Library routines required to 
specialize and order the described IOCS monitor. 
Some of the macro calls generated by SYSGEN 


are listed below: 


$A#IMSCP Global Area Initialization 
$A#IMIP Interrupt Packet Initialization 
$A#IMPIT PIOT Table Interfacing 
$A#IMCTL Logical Control Table 
$A#IMCTP Physical Control Blocks 


END DIRECTIVE 


CALL DIRECTIVE(S) 


ASGP - 
DIRECTIVE(S) 


SYSTEM 
~ GENERATOR 


PROGRAM 


ASGL 
DIRECTIVE 


SYSTEM 
MACRO 
LIBRARY 
FILE 


ACIC DIRECTIVE 
(OPTIONAL) 


TITLE DIRECTIVE 


$A#IMLSR Level Service/Restore 
Routines and Necessary 
Device Drivers and Device 
Service Routines 


SA#IMMSC MSC Service Routine 
$,A#IMOPL OPEN LUN Routine 
$A#IMCLL CLOSE LUN Routine. 
$A#IMACT I/O Action Routine 
$A#IMCLK Clock Routine 
$A#IMPAR Parity Routine 
$A#IMLOG Error Logging Routine 
$A#IMEXT EXIT Routine 
$A#IMPCB PCB Computer Routine 
$A #IMINT IOCS Initialization 


The output file from SYSGEN must be processed 
by the PTS-100 Assembler before the specialized 
IOCS monitor will be executable on the PTS-100. 
The total process of generating a system is 


illustrated in figure 3-4. 


ASSEMBLER 
FORMATED 
FILE 


PTS-100 


ASSEMBLER 
PROGRAM 


f EXECUTABLE 
| GENERATED 
SYSTEM 


Figure 3-4. Processing Flow of Specialized System Generation 
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To produce the Assembler formated file, the 
SYSGEN program reads, interprets, and pro- 
cesses the key word directives that compose its 
input. The processing performed depends on the 
particular key word directive that has been input, 


as described in the following subsections. 


4.2.1 TITLE Directive Processing 


When the first four characters of an input 
record are TITL, the SYSGEN program reads the 
parameters from the record and composes an 
Assembler options record containing the name of 
the system to be generated and any specified 
- assembly options. The first six characters of 
the input directive record (i.e., TITLE,) are 
discarded, and the output record begins with the 
name of the system, followed by the specified 
options. The record is written in Assembler 


formated file. 


4.2.2 ACIC Directive Processing 


“When an ACIC directive is input to SYSGEN, 
the parameters are read and SYSGEN generates 
a series of macro calls to effect the creation of 
specialized macro routines to support the channel 
interface controller and its attached devices. The 


first macro call is 
$A#IMCDPA nn, T 


which causes a specialized macro routine to be 
created from the generalized system macro 
routine #IMCDP, with the actual arguments nn 
(the number of devices specified in the ACIC 
directive) and T (the tumble table to be used) to 
be inserted in place of dummy arguments in the 
generalized routine. An additional macro call 
is generated for each device attached to the CIC, 


The macro calls take the form 


$\ HIMCCBAPTAG, CAD, PDAD 


where: 


PTAG is the tag of the Physical I/O Table 
(PIOT) to be used by IOCS. 


CAD is the channel address. 


PDAD is the physical address of a specific 
device within a group of devices attached to 


a channel. 


All macro calls are output to the Assembler 


formated file. 


4.2.3 ASGL Directive Processing 

When an ASGL directive is input to SYSGEN, 
the physical device notations are read, and a 
system logical macro call is generated in the 
format: 
Argument 


$4 #IMCT LAArgument : Argument | 


1’ a 


where: 


$ is the special symbol to signal the Assembler 


that a macro routine is being called. 


#IMCTL is the name of the generalized system 
logical macro routine to be specialized with the 


arguments in the call. 


Arguments 1 - n are the physical device nota- 
tions in the precise order in which they were 


specified.on the ASGL directive. 


The macro call is output to the Assembler 


formated file. 
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During Assembler processing, when the 
Assembler reads the macro call from the format- 
ed file, it locates the generalized #IMCTL macro 
routine on the System Macro Library file and 
creates a specialized macro routine by replacing 
the corresponding dummy arguments in the gen- 
eralized routine with the actual arguments in the 


SYSGEN macro call. 


4.2.4 ASGP Directive Processing 


When an ASGP directive is input to SYSGEN, 
the program issues the necessary macro calls to 
effect Assembler specialization of interrupt 
packets for all external interrupt levels io which 
devices have been assigned, creation of interrupt 
level servicing routines for each external inter- 
rupt level assigned, creation of a Physical Con- 
trol Block for each device assigned via the ASGP 
directive, and specialization of device driving and 


servicing routines. 


At assembly time, the Assembler creates 


specialized lOCS monitor routines to process 


interrupts from all assigned levels and accom- 
modate all devices within the described equip- 


ment configuration. 


4.2.5 CALL Directive Processing 

When SYSGEN reads an input CALL directive, 
it outputs the dollar sign ($) and the macro routine 
name specified in the CALL directive, followed by 
the argument string that the Assembler is to use 
in creating the specialized macro routine for the 


system being generated. 


4.2.6 END Directive Processing 


When SYSGEN reads the END directive in the 
input deck, it writes END as the last entry on the 
Assembler formated output file and terminates 


processing. 


At assembly time, the END statement ter- 
minates the assembly of the generated object 


LOCS monitor. 
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Section 5. PTS-100 DJIMP PROGRAMS 


There are two dump programs provided for board, as shown in figure 3-5. When input is 


use on the PTS-100: from a keyboard, the Dump program reads the 
dump parameters, executes the specified dump, 
@ The Memory Dump Program, which allows and recycles to indicate its ability to accept a new 
contiguous locations of main memory to be set of parameters via the printout 
dumped to a character printer, a magnetic 

RDY 
tape cassette device, or to a paper tape 


at the keyboard device. 


ASR 
- KEYBOARD 
PRESENT 


punch device. 


® The Peripheral Device Dump program, 
which provides for dumping serial binary 
data file records to a character printer 


device. 


These two programs and their utilization on the 


PTS-100 are described in detail in this section. 


5.1 Memory Dump Program READ OBTAIN 


ASR 
KEYBOARD 


PARAMETERS - PARAMETERS 
FROM FROM CALLING 
KEYBOARD SEQUENCE 


The Memory Dump program is a small, 
easily relocatable program capable of dumping 


the contents of contiguous locations of main 


memory to any sequential storage device that EXECUTE DUMP 


| ACCORDING TO. 
PARAMETERS 


DUMP 


DEVICE 


accepts variable length output records. The 


length of dump records depends on the output 


device being used. 


ASR 
KEYBOARD 
PRESENT 


There are two versions of the Dump program: 


° Version 1 dumps hard copy hexadecimal or | NO 


RETURN TO EXIT 
ADDRESS SPECIFIED 
BY CALLING 

PROGRAM 


ASCII records onto a character printing 


device. 


e Version Z dumps reloadable binary records 


to a magnetic tape cassette or paper tape Figure 3-5. Alternate Flow Paths of the 


nance wdeeiee Memory Dump Program | 


Either version of the program may receive dump 


parameters as input from a keyboard device or 
as arguments of a subprogram assembled within 
the main program whose memory locations are to 
be dumped. The Dump program follows one or 


two paths, depending on the presence of an ASR key- 


When dump parameters are passed from a 
subprogram within a main program, the Dump 
program executes the specified dump and returns 
control to the exit address transmitted from the 


calling program. 
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In all cases, the Dump program is located 


and activated by the Absolute/Relocating Loader. 


The inputs, processing, and outputs of 
Versions 1 and 2 of the Dump program are de- 
scribed in subsection 5.1.1 and 5.1.2 on sub- 
sequent pages of this section. 

5.1.1 Version 1 of the Memory Dump Program 

Version 1 of the Dump program dumps the 
contents of contiguous memory locations ona 
character printing device. The hard copy dump 
printouts are in either hexadecimal or ASCII 
representation of a maximum of 72 characters 
(i.e., one ASR print line) per record. The dump 
parameters may be input via a keyboard or via 
the object code of a subprogram assembled within 
a main (i.e., calling) program. The procedures 
for specifying dump parameters and the re sulting 


output are described below. 


Sede led Version 1 Keyboard Input Format. 


Each set of keyboard input parameters to the 

Version 1 Dump program must be specified as 
a 15-character line with no intervening spaces 
and in the precise order shown in the following 


format diagram: 


Character Position 


3- 6,7) 8-11 [12 113 14-15 


where: 


DU appears in character positions 1 and 2 to 


specify the dump. 


The STARting address of the dump appears as 
four hexadecimal digits in character positions 
3 through 6. 


A comma must appear in character position 7 to 
separate the starting and stopping: address of the 


dump. 


The STOPping address of the dump appears as 
four hexadecimal digits in character position 8 
through 11. 


A comma must appear in character position 12 
to separate the stopping address and the output 


format designator. 


The output format designator in position 13 must 
be an X if hexadecimal output is desired, or an 
A if ASCII format is to be used for the dump > 
output. 


Character positions 14 and 15 contain carriage 
return and line feed characters for the keyboard 


device being used. 


If an error is made in entering keyboard in- 
put parameters, the slash character may be used 
to negate all previously typed characters on a line, 
and the correct.entry may be typed immediately 


following. 


When a set of input parameters has been ter- 
minated by a carriage return/line feed, the 


Version 1 Dump program performs the following: 


° Stores the dump parameters in the symbolic 
memory locations #DFORM, #DSTAR, and 
#DSTOP. 


e Validates the dump parameters, and if they 


are valid performs the following: 


dumps the contents of the accumulator, 


- index register 1, and index register 2, 


| dumps the specified contiguous memory 
locations in the specified hexadecimal 
or ASCII notation. 
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e Signals its ability to accept another set of 
dump parameters by printing RDY on the 


character printer device. 


Dg le hed 
When Version | dump parameters are specified 
via a subprogram within a main program, they 
are transmitted to the Dump program in the 


following calling sequence: 


LX2 TAG 
JIMP #DUMP 
TAG ADC #* 
TAG] HEX 0000 starting dump address 
TAG2 HEX 0000 stopping dump address 
TAG3 HEX 0000 negative zero if hexa- 
decimal output desired, 
or negative one if ASCII 
output desired 
TAG4 HEX 0000 own code exit address 


When the dump parameters are transmitted 
to the Version 1 Dump program, it performs 


the following: 


e Stores the dump parameters in the symbolic 
memory locations #DFORM, #DSTAR, and 
#DSTOP. 


e  Validates the dump parameters, and if they 


are valid performs the following: 


dumps the contents of the accumulator 
and index register 1. Index register 2 
is not dumped since it is used to handle 
the calling sequence between the main 


program and the Dump program 


dumps the specified contiguous memory 
locations in the specified hexadecimal 
or ASCII notation 


returns control to the calling program at 


the specified exit address. 


Version | Calling Sequence Parameters. 


NOTE 


The Dump program does not 
restore registers prior to 
returning control to the call- 
ing program. | 


5.1.1.3 Version 1 Dump Output. Regardless of 


the specified format of Version 1 Dump program 
output, a given dump line begins with a 4-digit 
hexadecimal integer, which is the byte address 
(modulo 16) of the first byte or word in that line, 
followed by an asterisk (*), and the formated con- 


tent from the storage locations, as follows: 


@ If hexadecimal format was specified, eight 
data values are represented on a given line, 
each represented by four hexadecimal digits, 


followed by a space. 


@ If ASCII format was specified, 16 contiguous 
bytes of stored data are represented in 8-bit 
ASCII code per line. 


If all data values for a given output line are 
identical, only the first value is printed, prefaced 


by the word ALL, as shown below: 


OOOO*ALLAFFEFF 


If succeeding lines also contain the same 
value, line printing will be suppressed until some 
new data value occurs in the Dump data stream. 
For example, if locations 0 through 77 contain all 


ones the following would appear on the printout: 
0000*ALLAFFFF 


As mentioned above, if keyboard input is 
used, the value of the accumulator, Xl, and X2 
are printed prior to the specified dump. If call- 
ing sequence input is used, the value of X2 is 


not printed. 
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Formats of Version 1 Dump output are in- 


dicated below. 


e Register dump line, Keyboard Input Response: 


AC:0000A X1:4 0000,X2:A 0000 
° Register dump line, Calling Sequence Input 
Response: 


-AC:00004X1:40000 
e Hexadecimal format dump line: 


0000*1111A2222A333344444A55554666647777A8888 


@ ASCII format dump line: 


0000*ABCDEFGHIJKLMNOP 


e All hexadecimal or ASCII data values 


identical: 


OOOO*ALLAFFFF 


e Ready for Keyboard Input: 


RDY 


e Parameter error encountered: 


5.1.2 Version 2 of the Memory Dump Program 


Version 2 of the Dump program dumps re- 
loadable binary data. records onto a magnetic tape 
or paper tape device. The length of a given 
dump record is within the maximum allowable on 
the output device being used, The dump para- 
meters may be specified via a keyboard or via a 
calling sequence specified in object code assem- 
bled within a main program. The procedures for 
specifying dump parameters and the resulting 


output for Version 2 are described below. 


51261. Version 2 Keyboard Input Format. 
Each wet of keyboard input parameters to the 
Version 2 Dump program must be specified as an 
18- character line with no intervening spaces and 
in the precise order shown in the following 


diagram: 


Character Position 


a cian ae 


where: 


DU appears in character positions 1 and 2 to 


specify the dump. 


The STARting address of the dump appears as 
four hexadecimal digits in character positions 3. 
through 6. 


A comma (,) must appear in character position 7 
to separate the starting and stopping address of 


the dump. 


The STOPping address of the dump appears as 
four hexadecimal digits in character positions 8 
through 11. 


A comma (,) must appear in character position 
12 to separate the stopping address and the 


execution address. 


The dumped program's execution address must 
appear as four hexadecimal digits in character 


positions 13 through 16. 


Character positions 17 and 18 contain the carriage 
return and line feed characters for the keyboard 


device being used. 
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If an error is made in entering keyboard 
parameters, the slash character may be used to 
negate all previously typed characters on a line, 
and the correct entry may be typed immediately 


following it. 


When a set of input parameters has been 
terminated by a carriage return/ line feed, the 


Version 2 Dump program performs the following: 


@ Stores the dump parameters in the symbolic 
memory locations #DSTAR, #DSTOP, and 
#DEXEC, 


e Validates the dump parameters, and if they 
are valid dumps binary output to magnetic or 


punched paper tape. 


e Notifies the programer that it is ready to 


receive another set of parameters by printing 


RDY 


on the keyboard device. 


4.1.2.2 Version 2 Calling Sequence Parameters. 


When Version 2 dump parameters are specified 
via a subprogram within a main program, they 
are transmitted to the Dump program in the 


following call sequence: 


LX2 TAG 
JMP #DUMP 

TAG ADC x 
HEX 0000 starting dump address 
HEX 0000 stopping dump address 
HEX 0000 execution address 
HEX 0000 own code exit address 


When the dump parameters are transmitted 
from the main program to the Version 2 Dump 


program, it performs the following: 


e Stores the dump parameters at symbolic 
locations #DSTAR, #DSTOP, and #DEXEC. 
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e Validates the dump parameters, and if they 
are valid dumps binary output to magnetic or 


punched paper tape. 


® Returns control to the calling program at the 


specified exit address. 


NOTE 


The Dump program does not 
restore registers prior to re- 
turning control to the calling 
program. 


5.1.2.3 Version 2 Dump Output. The Version 


2 Dump program produces variable length dump 
records within the maximum size allowable on 
Each 


dumped record is in binary format and has a 


the device to which output is dumped. 


6-byte header containing the starting dump 
address, the number of bytes dumped, and the 


dumped program's execution address. 


5.2 | The Peripheral Device Dump Program 


The sole function of the Peripheral Device 
Dump (PDD) program is to produce printed list- 
ings of binary data files stored in one of the 


following mediums: 


cassette magnetic tape files 
punched paper tape files 


punched card files. 


The printed output produced by the PDD pro- 
gram is either in hexadecimal notation or ASCII 
code, as specified by the programer, or in hexa- 
decimal (default) notation if the programer does 
not specify the type of output listing to be pro- 
duced. The PDD program operates under con- 
trol of and in conjunction with the IOCS monitor, | 
which performs all I/O operations on the PTS- 
100. That is, since the function of the PDD 


program is to produce printed listings of data 


files, it must call the IOCS monitor to perform 
the read operations required to bring its inputs 
into memory and to perform all write operations 
to produce the printed listings of data files. 

. There are three logical file devices used by the 


IOCS monitor in servicing PDD program calls: 


® The system input device (SYSI), from which 
the monitor reads a PDD control director 
specifying the format of the output listing 
to be produced. | . 


@ The system data device (SYSD), from which 
the monitor reads the binary data file to be 
listed. | | 


e The system output device (SYST), to which 
the monitor writes the content of the spe- 


cified data file. 


The actual physical addresses of these 
devices must have been assigned when the 10CS 
monitor was generated by the System Generator 
program, described in Section 4 of this part of 
the handbook. The File Input/Output Blocks 
(FIOBs) and Input/Output Control Queue tables 
(IOCQs) required for each device by the IOCS 
monitor must have been created within the PDD 
I/O data 


buffer areas must have also been reserved in the 


program at system generation time. 


PDD program when it was generated. The buffer 
size selection should be the size required to. 
store any physical records to be read from the 
SYSD device. | | 


5.2.1 Inputs to the Device Dumping Process 


There are three inputs to the device dump- 


ing process: 


® The object code of the LOCS monitor and the 
Peripheral Device Dump (PDD) program, 
which must be loaded in that order by the 
Absolute/Relocating Loader. | 


@ A control director record specifying the 


desired format of the output listing. 


*. ‘Phe binary data file to be listed. 


5.2.1.1 IOCS Monitor and PDD Program Object 
Code. The object code of the IOCS monitor and 


the Peripheral Device Dump program must have 
been assembled by the PTS-100 Assembler. The 
actual physical device addresses of the SYSI, 
SYSD, and SYST logical file devices must have 
been assembled in the IOCS monitor. The 
necessary FIOBs and IOCQs for monitor use with 
these devices must have been assembled in the 
PDD program. The monitor and PDD program 
object code, illustrated as punch card Loader 
input in figure 3-6, must be loaded by the Absolute/ 


Relocating Loader. 


PDD EXECU- 
TION ADDRESS 


IOCS OBJECT 
CODE DECK 


Figure 3-6. IOCS Monitor and PDD Program 
Object Code Input to the Absolute/ Relocating 
Loader 


The IOCS monitor is an absolute program and 
must be loaded first. Furthermore, the execution 
address of the PDD program must be specified, 
since the PDD program must initialize itself and 
subsequently call the monitor to read its inputs 
from SYSI and SYSD. Hence, the PDD program 


must appear at che end of the input to the Loader. 


Be ee Lae 


PDD Conkel Director RéeeRa: The 


PDD control director record is an 80 elaeacies 


record formated in the medium required by the 


System Input Device (SYSI). 


positions and usage on the control director record 


The character 


are as follows: 


Character 


positions 1-3 


Character 
position 4 


Character 
position 5 


These character positions may 
contain the characters ASC to 
specify that the output listing is 
to be in ASCII code; the char- 
acters HEX specify that the lst- 
ing is to be in hexadecimal 
notation; any other characters 
produce a default listing in hexa- 
decimal notation. 


This character position is not 


used and must therefore be blank. 


This character position is not 
used except when the data file to 
be listed is to be read froma 
cassette magnetic tape, in which 


case the particular cassette 
transport to be used must be 


specified. 
Character These character positions may 
positions optionally be used to enter a 
30 - 80 comment to be printed on the 


header line of the output listing. 
There is no restriction on the 
starting position of the first 
character of the comment. That 
is, it may begin in any position 
after 29 and range through 
position 80. The comment is 
printed exactly as it was speci- 
fied on the director record. The 
comment field is useful for 
supplying dump identification, 
destination, etc. 


The control director record, illustrated in 
punch card format in figure 3-7, must be ready 
in the System Input Device (SYSI) when the PDD 


program is initialized. 


0 = cassette transport 0 
1 = cassette transport | 
ASC 2 = cassetie transport 2 
3=c 


HEX assette transport 3 


On 6 
>» lable? 
: Wy | 


fh 
u 
@o flee hs 225% oF ha 


COMMENT 


de oS O00 Gu AB TIS DUFHOVHGCHIOCOVOCAOOOTAHDANDNAGAKOCHAHNALHAOGHODCHD 


» V0 35:34 55 Sb Zi 58 99 40 At 42 43 44 45 46 47 48 49 SO St 52 53 54 55 56 57 5B 59 60 81 62 63 64 65 G6 £7 68 69 70 71 72 73:74:75 76 77: 78 79 80 


ee SERRAR DR ERAADEE) | PETER TTPEETTTPPET TTT ETT TTT TT TTT TTT adda ddd 


aaah ble 220002002 2202002222202 222 20022222022 2 222022022222222 220020222 £2222 22222 


43998 3939393 33999399393993 5398999 993399999399939333999393899389999399999825933993999 


44M dda dggas saad 
5955555555555 


Pee) Cee ee 
$99$955999955559599599555555555955555555 


Sawa ae 


| 
PTT TTT TT ATT TTT TTT TCT TT ATT TRA TTT TTT TTT TT TAT TTT TTT TTT TTA T TTT TT Tae 
saiilovesecguuveusnnnnnanssopecnuassccasconcanuscacosncgssnsusnazessuussvecate 

, eee 199959999999999S9999999999999S999999N9999g9995 993999999999999999 


$i ded HG 7 BLY 202i 22 23.24 23 26 27 cB ZOE i 32 33:34 35 38 37 $8 38 AO 41 42 43 44 45 46 47 48 49 58 51 $2 93 54 $5 56 57 58 59 60 61 67 63 64 65 60 67 68 Gs 70 7) 72.73 74:75 76 77 7373 80 


IBM eon 


Note: Column 5 would be used only when ‘he data 
file is on a cassette tape to be read from 


_SYSD. 


Figure 3-7. - 
System Input Device (SYSI) 


PDD Control Director Record Format, Assuming the Card Reader as the 


5.2.1.3 Data File. The data file to be listed 
must be in binary format in a serial storage 

medium, and must be ready in the System Data 
Device (SYSD) prior to initialization of the PDD 


program. 


The size of records in the data file must be 
no greater than the size of the input buffer area 
reserved in the PDD program at system genera- 
tion time. The programer should consult the 
documentation of his particular version of the 
PDD program if in doubt about the maximum 
record size that can be dumped. Typically, a 


record size of 200) 9 words is used. 


5.2.2 Peripheral Device Dump Processing 


To initialize the Peripheral Device Dump 
program the programer must perform the 


following: 


1, Load the object code of the IOCS monitor and 
the PDD program via the loading procedure 
described in Section 2 of this part of this 
handbook. - 


2. Prepare a control director record, place it 
in the System Input Device, and ensure that 


the device is ready. 


3. Place the data file to be dumped in the Sys- 
tem Data Device and ensure that the device 


is operational. 


When the Absolute/Relocating Loader has 
finished loading the PDD program, it activates 


the program at its starting address. The PDD 


program initializes its buffers, tables, vee ables; 
and constants, and then issues a call to the IOCS 

monitor to read the control director record from 
the SYSI device. 


into the reserved storage area within the PDD 


The monitor reads the record 
program. 


The PDD program reads and interprets the 
control director and performs the necessary 
actions to set up for the conversion from binary 
input data format to either ASCII code or hexa- 
decimal output format, as specified by the con- 
trol director. PDD then calls the monitor to 


print the output listing header either as 


ASCIL DUMP 
HEX DUMP 


(comment) 
or | 


(comment) 


When the header has been printed, IOCS 
returns control to PDD, which then calls the 
monitor to read a record from the data file on 
the SYSD device. 


record into PDD's input.buffer area. 


IOCS reads a binary input data 
PDD then 
reads the record, converts it to the required 
format, moves the converted record to the output 
buffer, and calls IOCS to print the record on the 
SYST listing. IOCS prints the record header 
(i.e., the word RECORD, followed by the record 
number), spaces to the next line, and prints the 


converted data values of the record. This pro- 


cess continues until the last record from the data 
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file has been read, converted, and printed. At 
this point, the PDD program calls the IOCS 
monitor to close the SYSI, SYSD, and SYST 
devices, after which PDD exits from the system. 
The functional processing flow between the PDD 
program and the IOCS monitor is illustrated in 


figure 3-8. 


PDD receives control from Loader, 
initializes its variables, tables & 
buffers, & calls IOCS to read di- 
rector record from SYS|I 


PDD 


PDD processes control director, 
sets up for ASCII or HEX output 
conversion, & calls 1OCS to 
print output listing header 


IOCS prints header on SYST & 


IOCS reads one recat from SYSI 
& transfers record & control to 


returns control to PDD 


PDD calls IOCS to read SYSD 
data file 


IOCS reads a record from SYSD 
data file & transfers it & control 
to PDD 


NOT PDD converts binary record to 
EOF ASCII or HEX & calls IOCS to 
print record 


PDD checks for end of file 


EOF 


PDD calls IOCS to close devices 


PDD exits from the system 


ee ee IOCS closes devices and returns 
[PD exis fom hese ses 


Figure 3-8. Functional Flow of Peripheral Device Dump/IOCS Monitor Processing 


5.2.3 Peripheral Device Dump Program Output 


The output from the PDD program is a hard 
copy listing of the input data file. The listing 
will be in ASCII code or hexadecimal notation, 
depending upon whether the programer specified 
ASC in columns 1 - 3 of the control director 
record. Thatis, the programer may specify 
ASC, HEX, or leave these columns blank. If 
the characters HEX or blank characters appeared 
in these columns the output listing will be in 


hexadecimal notation. 


The output listing will contain a header line 
indicating the type of dump output, followed by 
the comment, if any, specified in columns 30 
through 80 of the control director. Each record 
is identified on the listing, and the record identi- 
fication is immediately followed by the data in the 
record. ASCII and hexadecimal output listing 


are illustrated in figure 3-9. 


IOCS prints record on output 
SYST Listing & returns control 
to PDD 


ASCII DUMP 


RECORD 001 
DATA 


RECORD 002 
DATA 


RECORD nnn 


HEX DUMP 


RECORD 001 
DATA 


RECORD 002 


DATA 


Figure 3-9. 
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paper 
tape 


SYST . 


cass 


Listing tape 


COMMENT 


COMMENT 


ASCII and Hexadecimal PDD 
Output Listing 


Section6,. FILE UPDATE PROGRAM 


This program provides a convenient, easily 
used method of filing, maintaining, and updating 
source and object programs. That is, the File 
Update program may be used to create a master 
file containing either object or source programs, 
or both object and source programs, and subse- 
quently to maintain and update the master file. 
Object programs may be maintained on a pro- 


gram basis only. 


The File Update program may be directed to 


perform the following functions: 


e Insert one or more programs on the master 
file. 


r Delete one or more programs on the master 
file. 


r Correct programs on the master file by 
changing their names and/or deleting, 


replacing, or inserting lines. 


6 Replace one or more programs on the 


master file. 
e Produce a master file directory. 


e Block primary files (320 bytes/record), if 


specified in option field. 


The File Update program utilizes the IOCS 
There- 


fore, the monitor must be loaded and operational 


monitor to perform all I/O operations. 
prior to initialization of the File Update program, 
File Update program processing is specified 


via four types of input directors, described in 


subsection 6.1 below. 


6.1 Input Directors 


Four types of directors are input to the File 


Update program: 


rae ore | 


e Program directors, which specify actions to 
be taken on an entire program on the master 


file, 


e Data line directors, which specify actions to 
be taken for one or more Specific lines 


Within a given program on the master file. 


@ The END director, which terminates the 
inputs to the File Update program. 


e The EOF director, which writes an end of 
file record (1EOF) on the master file and 
terminates the File Update program 


immediately. 


The input directors are read from the Sys- 
tem Input (SYSI) device. If the File Update pro- 
gram is to produce the first version of a master 
file, only one type of Program director, the 
Insert director, the associated object or source 
program code, and an EOF director are required 
as input from the System Input device. No other 
input is required. If, however, the File Update 
program is to update an existing master file of 
programs, the current master file must be input 
via the System Data (SYSD) device, and the 
appropriate directors must be input via the SYSI 


device. 


The File Update program processes the input 


directors to produce the following outputs: 


° The original or updated version of the master 
file, which is written to the Logical Unit A 
‘LOGA) device. 


ee 2 listing of changes specified by the direc- 
tors and any errors detected in the input 
directors and, optionally, a file directory 
on the System List (SYST) device. 


e Card image format (if specified) on the 


System List (SYST) device. 


The four types of input directors andthe 
File Update processing of the directors are de- 
scribed in the subsections 6.1.1 through 6. 1. 3. 
The outputs from the program are described in 


subsection 6. 2. 
6.1.1 Program Directors 


The program directors specify actions to be 
taken for an entire program. They may be com- 
posed of five fields, as shown inthe following 


pena eo format diagram. 


IField l Field z Field 3 Field 4 Field 5 


comments 


| current 
program ae ere 
name 


options 


where: 


Field 1 contains one of the 5- character 
identifiers for the four directors, each of 
which begins with a $ in record position l, 
and ends with the letter P in record position 
5. The specific action to be performed is 
indicated by the three intervening alphabetic 
characters (xxx) , which must be one of the 


following: 
INS specifies that a new program is to be 
INSerted on the updated master file. 


DEL specifies that one or more programs 


are to be DE Leted from the master file. 


COR specifies that a program on the master 


file is to be CORrected. 


*The N and F options are mutually exclusive. 


specifies that a new program is to 
REPlace a program currently on the 


master file. 


Field 2 contains the name, up to eight char- 
acters in length, of a program on the master 
file. The name begins in position 6 and may 
range through position 13 of the input direc- 
tor. The named program is to be processed 


as specified in Field 1. 


Field 3 contains the name of a new program 
to be assigned as specified by the identifiers 
$INSP, $REPP, or $CORP, or the name of 
the last program in a string of programs to 
be deleted from the master file. The name 
begins in position 14 and may range through 


position 21 of the input director. 


Field 4 may contain option designators to 
effect specific types of output by the File 


Update program, as follows: 


specifies that the program about to be 


inserted is in binary format. 


Nor F_ specify, respectively, that no file direc- 


tory is.to be produced (i.e., N), or that 
a full file director (F) is to be produced.” 
A full file directory will consist of all 
header records being listed on the SYST 
device for those programs remaining on 
the master input device. For this 
reason, no other processing is allowed 


if the F option is specified. 


specifies that the program being cor- 
rected will be listed in card image 
format on the SYST device. (This 
option is valid only for the $CORP 


command. ) 


specifies primary files will be blocked 


(320 bytes/record). 


That is, only one of the options should be specified, 


since the first one will be accepted and remain in effect to be acted upon by the File Update program. 
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The options start in position 22 and mav 
range through position 24, 
in any order. They are terminated by the 


first blank character in Field 4, 


Field 5 may contain a comment to be 
carried in the header record when a pro- 
gram is to be inserted, corrected, or re- 
placed. The comment appears in positions 
30 through 80 of a given input program di- 


rector, 


The program directors cause a search 
forward and copy function to be performed by 
the File Update program. That is, the input 
master file is searched and copied onto the out- 
put master file until the program named in Field 
2 of the program director is found, at which 
point the File Update program performs the ac- 
tion specified in Field 1. It is for this reason 
that actions on programs must be specified in. 
the exact order in which the programs appear 
on the master file, as indicated on the file 
directory, which may be obtained from the File 


Update program. 


The individual program directors, their 
formats and content, and the processing speci- 


fied by them are described in detail below. 


6.1.1.1 Insert Program Director ($INSP). 


INSert program director is used to add one or 
more new programs to an existing master file, 
or to create the master file initially. The 


format of the director is shown below; 


| option(s) 


current 
program 
name 


The $INSP identifier must appear in Field 1 
of the input record. If an existing master file is 
being updated, the name of the program after 


which the new program is to be inserted may 


They may appear 


The 


| Field : Field 2 Field 3 Field 4 Field a 


“ | 
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appear in Field 2. If no name is specified in 
Field 2, the new program will be inserted at the 
current location at which the master file is 
positioned when the $INSP director is read. 
That is, the File Update program will insert 
the new program immediately following the last 
program for which it performed processing as 
specified by the previous program director, or 
at the beginning of the file if the $INSP director 
is the first director read by the File Update 


program. 


If the master file is being created initially, 
Field 2 would not be used in the $INSP director, 
That is, the File Update program would merely 
write the object or source programs onto the 
output master file in the sequential order in 
which they and their $INSP directors were read 
from the SYSI device. A name must be assigned 
to the new program by entering it in Field 3. If 
this field is all blanks, an error message will 
be generated and the director will be ignored. 
No blank headers are allowed. If a name is 
specified or assigned in this field, a header 
record will be created and written preceding the 
new program's code on the output master file. 
The header will contain the name and the infor- 
mation, if any, specified as a comment in 


Field 5 of the director. 


The source or object records of the program 
to be inserted must immediately follow the $INSP 
director in the input file being read by the File 
Update program. If object records are to be 
read, the B option must be specified and the 
last object record per program must be a multi- 
punched 2-7-8-9 record (standard object end of 


file mark). 


6.1.1.2 Delete Program Director (6DELP). 


The DELete program director is used to specify 
that a single program or a string of consecutive 
programs is to be deleted from the master file. 


The format of the director is diagramed below. 


Field 1 Field 2 Field 3 

“name 

| program program 
name 1 name n 


The $DELP identifier must appear in Field 


1, If only one program is to be deleted, its 


name must appear in Field 2. Ifa string of 
consecutive programs is to be deleted, the | 
name of the first program to be deleted must 
appear in Field 2, and the name of the last pro- 
gram in the string must appear in Field 3. No 


other fields are used on this director, 


The single name director causes the File 
Update program to delete the named program. 
That is, the header record and the program 
code associated with it are not written onto the 
output master file. If the delete director 
specifies that a string of programs is to be de- 
leted (i, e., if Field 2 and Field 3 both contain 
a program name), the File Update program 
skips all programs and their header records, 
beginning with the first program and going 
through program n, when it reads the input 
master file. That is, none of these programs 
is copied onto the output master file. Any 
header records associated with the deleted pro- 


grams are also deleted. 


6.1.1.3 Correct Program Director ($CORP), 


The CORrect program director specifies that a 
program on the master input file is to be correc- 
ted. The permissible formats of the director 


are shown below: 


Field 1 Field 2 = 3 nae 4 poe 5 


an ion 
ek, 


$CORP | progname pro |progname| | 
old 
program 
name 
old 

program 
name 


new 
program 
name — 


The $CORP identifier must appear in Field 
1, and the name of the program to be corrected 
must appear in Field 2. If the program is to be 
assigned a new name, it must appear in Field 3. 
Optional outputs may be specified in Field 4, and 
any information to be carried in a header record 
for a program assigned a new name may appear 


in Field 5. 


The $CORP director must be followed with 
the necessary data line directors (see subsection | 
6.1.2) to effect the desired program corrections, 
such as deleting or replacing lines in the origi- 
nal program, or inserting new lines in the pro- 


gram. 


When the $CORP director specifies a new 
program name in Field 3, the File Update pro- 
gram creates a new header record containing the 
new name and the comment, if any, in Field 5. 
The header record is written onto the master 
output file, and the File Update program then 
processes the data line director to create and © 
write the corrected program code following its 
associated header record on the output master 
file. 


If Field 3 does not contain a new program 
name, the original header record is transferred 


to the output master file, followed by the correc- 


ted program. 
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When all data line directors following the 
$CORP director have been processed, (i.e., 
when File Update reads a new program director), 
the correction process for this program is 
completed. Any remaining lines in the original 


program are copied to the output master file. 


The $CORP director may be used to obtain 
a file directory printout without actually per- 
forming an update run. This is effected by using 
only the $CORP director, and $END director, 
and the input master file as inputs to the File 
In this case, the $CORP direc- 


tor would contain the following: 


Update program. 


$CORPprogname 


where ''progname'' is the name of any pro- 

gram known to be stored on the input master file. 
No other information (except for an F in the 
option field for a full directory) is specified on 
the director, which is followed immediately by 
the $END director. This director causes the 
File Update program to read the input master 


file and produce the directory on the SYST device. 


6.1.1.4 Replace Program Director ($REPP). 


The REPlace program director specifies that a 
program on the master file is to be replaced by 
the program whose source or object code imme- 


diately follows the director. The permissible 


formats of the director are diagramed below: 
Field 1 | Fielad2 | Fielad3 | Fiela4| Fiela 5 


old | option(s) 
program | 
name. 


, option(s)}/comment 
program | program | | 


The $REPP identifier must appear in Field 
1, and the name of the program to be replaced 
must appear in Field 2. Field 3 may optionally 
specify a name to be assigned to the new pro- 
gram. If a name is specified in Field 3, Field 5 
may optionally specify a comment tobe carried 
in the header record that the File Update program 
| If Field 3 does 


not contain a name, no new header record will be 


will create for the new program. 


created. 


The source or object records of the new pro- 
gram must immediately follow the $REPP 
director. If object records are to be read, the B 
option must be specified and the last object record 
must be a multi- punched 2-7-8-9 record (standard 


object end of file mark). 


6.1.2 Data Line Directors 


These directors specify actions to be taken 
for one or more lines within a given program 
named on an immediately preceding $CORP 
program director. There are three data 
the INSert director, the DELete 
The 


generalized format of the data line directors is 


line directors: 


director, and the REPlace director. 


shown below: 

Field l Field 2 Field 3 

$xxx A line | line 
number number 


where: 


Field | contains one of the 4-character 
identifiers for the three directors, each of 
which begins with a $ in record position 1 
and ends with a blank character in position 
5. The specific action to be performed is 
indicated by the three intervening alphabetic 
characters (xxx), which must be one of the 


following: 


INS specifies that one or more data lines 
are to be inserted in the program. _ 

DEL specifies that one or more data lines 
are to be deleted from the program 

REP specifies that a data line is to be re- 


placed by one or more data lines. 


Field 2 contains the logical line number 
(positions 6-9) after which new data lines 
are to be inserted, or the first line to 


be replaced or deleted. 


Field 3 contains the logical line number 
(positions 14-17) of the last data line to 
be deleted. 


The logical line numbers are kept within the 
File Update program. That is, the program 
associates a number with each line in any given 
source or object program on the input master 
file. 
will be maintained according to the order of 
That is, the 


File Update program will associate numbers 


For source programs, the line number 
appearance of source statements. 


from 1 to n with each source statement read 


from the file. 


6.1.2.1 Insert Data Line Director ($INS). The 


INSert data line director specifies that the data 
line(s) immediately following it are to be inserted 
in the existing program following the specified 
logical line number. The format of the director 


is shown below: 

Field 1 Field 2 |. 
$INSA line 

| | number 


The $INS identifier must appear in Field 1, 
and be followed by a blank. 


Field 2 must contain the correct line num- 
ber. following which the data line(s) are to be in- 
serted. The data lines must immediately follow 


the INSert director. 


6.1.2.2 Delete Data Line Director ($DEL). 


This director specifies that one or more existing 
lines in the subject program are to be deleted. 


The format of the director is shown below: 
Field 1 Field 2 Field 3 


$DELA line 
number | 
line line 
number number 
1 n 


The $DEL identifier must appear in Field 1, 
and be followed by a blank. Field 2 must con- 
tain the logical line number of the single line to 
be deleted or the first logical line number ofa 
series of lines that is to be deleted. If only one 
line is to be deleted, Field 3 is not used. Ifa 
series of consecutive lines is to be deleted, 
Field 3 must contain the logical line number of 


the last line to be deleted. 


When a $DEL data line director is read by 
the File Update program, the specified lines 
are skipped when the program named ona 
$CORP program director is written on 


the output master file. 


6,1.2.3 Replace Data Line Director ($REP). 


The format of this director is shown below: 


Field | : Field 2 Field 3 
| number _ 


The $REP identifier must appear in Field 1, 
followed by a blank. Field 2 must contain the 


logical line number of the single line to be re- » 
placed. The replacement lines must follow 


the $REP director. 


6.1.3 END Director (SEND) 

The END director signals the end of the in- 
put data stream to the File Update program. It 
is written in record positions 1-4 in Field 1 


simply as 


$END 


When the program reaches the END director, it 
copies the remaining portion of the master input 
file to the master output file. It then produces a 
file directory (unless it has been suppressed by 
the N option on a program director record) and 


terminates processing. 


6.1.4 EOF Director (SEOF) 


The EOF director causes an end of file 
record (1EOF) to be written on the master output 
file. This will be followed by the production of a 
file directory (unless it has been suppressed by 
the N option on a program director record) and 
the processing terminates. This director is 
intended to be used when initially putting pro- 
grams on the master output file using the $INSP 
director. If used, it takes the place of the $END 
director, which also copies the remainder of the 


master input file. 


6.2 File Update Program Outputs 


There are three standard outputs from the 


File Update Program: 


e The updated master file on the Logic Unit A 
(LOGA) device, containing all correctly 


submitted corrections and programs. 


@ A listing on the SYST device of all updates 


submitted to the File Update program, with 
embedded error printouts indicating any 
illegal input directors and the cause of the 


error conditions. 


e A printout on the SYST device of the file 


directory, unless it was suppressed by the 


N option on a program director. 


The file directory contains the program 
name for each program onthe master file. This 
information is printed in the exact order in which 
the associated program appears on the updated 
master file. Nonstandard outputs may be re- 
quested via the option designator Lin Field 4 of 
program directors as described earlier in this 


section. 
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Section 7. 


7.1 Disc Volume Preparation Program 


This program initializes a new disc for use 
in the PTS-100 system. 


erase the information on an old disc to prepare 


It may also be used to 


it for reuse. A disc must be preprocessed with 
the Disc Volume Preparation program whether 
it is to be accessed by physical or logical input/ 


output. 


The Disc Volume Preparation program per- 


forms three functions: 


e Accepts from the card reader a set of para- 
meters describing the desired format of the 


disc. 


Formats and checks the disc surface. The 
program executes the Write Address opera- 
tion on each track of the disc surface, checks 
whether each track can be read without error, 
and issues messages indicating any tracks 


that cannot be read. 


Writes out the Volume Label and makes an 


initial entry in the Volume Directory. 


Table 3-8, 


Parameter 


Keyword and Value 


Disc drive number DRIVENO=n 


VOLSER=aaaaaa 


Volume serial number 


Address of start of Volume 


| VOLDIRSTRT= 
Directory nnn/nn/nn. 
Last cylinder in Volume VOLDIRLAST= 
Directory nnn 
Number of tracks per TRACKS =nn 


cylinder 


Number of cylinders per 


_ CYLINDERS =nnn 
- disc . 


Disc Volume Preparation Program Parameters 


DISC SUPPORT PROGRAMS 


This program assumes that the disc is to 
have 320 data bytes per sector, and 20 sectors 
per track. The number of tracks per cylinder 
and number of cylinders per disc are variables, 


which are accepted as parameters. 


Disc Volume Preparation is a standalone 
program; it does not use the IOCS monitor. All 
input and output for the disc, the card reader, 
and the serial printer are handled directly at the 
physical level. 


7.1.1 Input to the Disc Volume Preparation 


Program 


Input consists of a set of six free form para- 
meters read by the card reader. Each parameter 
value is preceded by an identifying keyword. All 
six of the parameters listed in table 3-8 must be 
specified; they may be punched on any number of 
cards. If several parameters are punched on one 
The 


parameter cards must be followed immediately by 


card, they must be separated by commas. 


a card with /* punched in columns 1 and 2. 


Des cription 


nis a number from 0 to 7, designat- 
ing the drive address to be formated. 


aaaaaa is any six characters used to 
identify the disc. 


The parameter value is a disc address 
in the form cylinder/track/sector. 
The Volume Directory will start at this 
address. 2 | 

nnn is the last cylinder number to be 
assigned to the Volume Directory. 


nn is the number of tracks per 
cylinder on the disc to. be processed. 


nnn is the total number of cylinders 
on the disc to be processed. 


an a 


7.1.2 Disc Volume Preparation Program Output 


The major output is a disc on which all 
tracks have had correct addresses written and 
with all tracks checked to see that they eae 
read and written. For each track that cannot be 
read and written correctly, the following mes- 


sage is printed on the serial printer’ 
BAD TRACK ee 
where nnn/nn is cylinder/track. 
As part of the output, the volune Label is 


written on the disc at location cylinder 0, track 


0, sector 0. It has the following format: 


Volume serial number 6 bytes 
Address of start of Volume 4 bytes 
Directory 

Last cylinder number in 2 bytes 
Volume Directory 

Highest track number in 2 bytes 
cylinder (track number 

is in bits 2-4) 

Highest cylinder number in disc 2Z bytes 


Unused remainder of sector 


7.1.3 Processing 

The processing done by the Disc Volume 
Preparation program can be separated function- 
ally into three segments: parameter input, for- 


mating and checking, and volume initialization. 


7.1.3.1 Parameter Input. Input cards are read 
until a card is found with */ in columns I and 2. 
As each card is scanned, the six keywords are 


isolated and identified. 


If the keyword is not recognized, the serial 
printer prints out the message UNRECOGNIZED 
KEYWORD, followed by the word as read from 
the card. 


If the parameter keyword is recognized, a. 


routine is entered for converting (if necessary), 


Surface. 


checking, and storing the value. If the value is 
outside permissible limits, the serial printer 
prints out the message PARAMETER ERROR, 


followed by the keyword. 


7.1.3.2 Formating and Checking the Disc | 
Using the parameters disc drive num- 
ber, tracks per cylinder, and cylinders per pack, 
the entire disc surface is formated by means of 
the Write Address operation. If this is not suc- 
cessfully completed, it is retried three times be- 
fore a BAD TRACK message is written on the 


serial printer. 


After the Write Address operation is performed 
for each track, an attempt is made to read each 
sector in the track, to see that it is all zeros. If 
not, the read is retried three times before a BAD 
TRACK message is written. 
7.1.3.3 Volume Initialization. Using the para- 
meters provided on the input cards, the Volume 
Label is written. Also, an end-of-directory 
record is written at the beginning of the Volume 


Directory area. 


7.2 Disc Allocator Program 


The Disc Allocator assigns disc space to 
files, extends the disc area allocated to files, and 
deletes files. It must be used in connection with 
the logical IOCS for disc. 


written or read through the logical input/output, 


Before any file can be 


it must be allocated on a disc by the Disc Allocator 


program. Ifa disc is to be accessed by means of 


- physical input/output only, it is not necessary to 


process it with the Disc Allocator program. 


Prior to running the Disc Allocator the disc 
must be initialized by means of the Disc Volume 
Preparation program. Disc Volume Preparation 
writes the Volume Label, from which the Disc 
Allocator obtains the Volume Directory limits, 
the number of tracks per cylinder, and the num- 


ber of cylinders per disc. 


The program operates from free form keyword 


type parameters read from the card reader. 
7.2.1 Input to Disc Allocator Program 


Input consists of free form parameters read 
by the card reader. Each parameter value is pre- 
ceded by an identifying keyword. Different com- 
binations of parameters are required, depending 
on the function being requested and the file organ- 


ization involved. 


Several files may be allocated in one program 
run. A new file is indicated by the appearance of 
a FILENAME parameter. 


ing that one, up to the END card or another FILE- 


All parameters follow- 


NAME parameter, are assumed to apply to the 


same file. 


Except for the FILENAME parameter, the 
parameters may appear in any order. If several 
parameters are punched on one card, the para- 
The last 


parameter card must be followed by a card with 


meters must be separated by commas. 
/* punched in columns 1 and 2. 


Table 3-9 lists the parameters, their key- 
words, their permissible values, and rules 


governing their use. 
7.2.2 Disc Allocator Program Output 


The Disc Allocator has two outputs: one to 
the disc and one to the serial printer. The output 
to the disc consists of an entry in the Volume 
Directory (in the format shown in subsection 
tale 2. 1) and of the file area itself, which is 
initialized to zeros. The output to the serial 
printer consists of the messages listed in sub- 


section 7.2.2.2. 


dy Cé0ek 
Directory. 


Disc Allocator Entries in Volume 


Each entry in the Volume Directory 


contains the following ten fields: 


(1) 


(2) 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 


(9) 


Banner word (2 bytes): 


0000, 


0001 16 if active 
FEDC 


6 if unused 
16 if end of directory 
File name (10 bytes). This is the name by 


which the file is always accessed in programs 


that manipulate it. It is assigned by the user, 


and can contain any characters. 
First cylinder number in file (2 bytes). 
Last cylinder number in file (2 bytes). 


File organization (2 bytes): 


K = random organization with keys 
N = random organization without keys 
S = sequential organization. 


Number of sectors per block (2 bytes); applies 


to random access only. 


Record size (2 bytes). This is the number of 


bytes per record; it must be an even number. 


Whether record is fixed or variable in length 
(2 bytes): 
F = fixed 


V = variable 


Address of start of overflow area (2 bytes); 
applies to random files only; 0 signifies no 


overflow area. 


(10) Reserved for expansion (26 bytes). 
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Parameter 


File name 


Drive number 


Function 


First cylinder 
in file 
Last cylinder 


in file 


File 
organization 


Record type 


Record size 


Overflow 
cylinder 
address 


Table 3-9. Disc Allocator Program Parameters 


Keyword and Value 


FILENAME = aaaaaaaaaa 


DRIVENO =n 


| | NEW 

FUNCTION =( EXT 
DEL 

FIRSTCYL = nnn 


LASTCYL = nnn 


FILEORG = 


RECTYPE 45} 


RECSIZE = nnn 


AAW 


OVERFLOW = nnn 
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Use 


The file name must be the first parameter 
in a group of parameters applying to a par- 
ticular file. The parameter value can con- 
sist of any characters, and any number of 
characters up to ten. | 


nis a number from 0 to 7, identifying the 
device number on which the disc is mounted. 
If this parameter is omitted, device number 
0 is assumed. 


The function parameter indicates whether a 
file is being allocated (NEW), extended 
(EXT), or deleted (DEL). This parameter — 
must always be present. 


This parameter identifies the first (lowest) 
cylinder number to be allocated to the file. 
It must be present whenever FUNCTION =NEW. 


This parameter identifies the last (highest) 
cylinder number to be allocated to the file. 
For random files, it includes the overflow 
area, ifany. This parameter must be 
present whenever FUNCTION =NEW or EXT. 


This parameter indicates whether a file is 
random organization with keys (K), random 
organization without keys (N), or sequential 
organization (S). This parameter must be 
present whenever FUNCTION = NEW. 


This parameter specifies whether the records 
in a file are fixed (F) or variable (V) inlength. 
Only F may be specified for random files. If 
this parameter is omitted, F is assumed. 


This parameter gives the number of bytes per 
record and must be an even number. It must 
be present whenever FUNCTION = NEW and 
RECTYPE =F. 


This parameter indicates the lowest cylinder 
number of the overflow area for a type K file. 
The overflow area extends from this cylinder 
to the last cylinder in the file (LASTCYL). 
This parameter should be included only when 
FUNCTION = NEW and FILEORG = K. If the 
overflow parameter is is omitted, it is assume d 
that there is no overflow area. 


7.2.2.2 Disc Allocator Output to Serial Printer. 
The Disc Allocator program outputs the following 


messages to the serial printer: 


FILENAME = aaaaaaaaaa 


This message is printed whenever a new 
FILENAME parameter is read. The file 
name identifies the file to which the 


following message applies. 


UNRECOGNIZED KEYWORD keyword 
PARAMETER ERROR keyword 
PARAMETER OMITTED keyword 
VOLUME DIRECTORY OVERFLOW 
FILE NAME ALREADY USED 

FILE AREA UNAVAILABLE 

FILE NOT FOUND _ 

BAD TRACK nnn/nn (cylinder/track) 


7.2.3 Processing 


The processing done by the Disc Allocator 
program can be separated functionally into four 
segments: parameter input, check of Volume 
Directory against parameters, entry of parameters 
into Volume Directory, and initialization of new 


file area to zeros (with a read check). 


The first program segment reads and checks 
the parameters. Each card is scanned, and in the 
process each keyword is updated and identified. 

If the keyword is not recognized, or if the value is 
outside its permissible limits, an error message 
is printed. When all the parameters for one file 
have been read, the resulting parameter table is 
examined to see if all required parameters have 
been specified. If not, an error message is 


printed. 


The second segment checks the Volume 
Directory against the parameter list to see if the 


requested action can be performed. It checks to 


see that a new name is unique, that specified file 
limits do not conflict with any existing file, and 
that there is room in the Volume Directory for a 


new entry. 


The third segment makes the necessary entry 
in the Volume Directory. This may be a deletion, 
anew entry, or an alteration to an old entry, de- 


pending on what function was requested. 


The fourth segment initializes the new file 
area to zeros and checks that it can be read back, 


issuing an error message if it cannot be. 
7.3 Disc Dump Program 

The sole function of the Disc Dump program 
is to produce a printed listing of data on allora 
selected portion of any disc unit is use with the 


PTS-100. 


printer in either hexadecimal or ASCII notation, as 


The output is listed on the serial 
specified by the input directives. All dump para- 
meters are input from a display or teletypewriter 
keyboard in response to program messages. As 

indicated in Figure 3-10, the PTS-100 Disc Dump 
program is a standalone program; it does not use 


the IOCS monitor. 


KEYBOARD |\ 


DISC DUMP 
UTILITY 
PROGRAM 


SERIAL 
PRINTER 


Figure 3-10. Disc Dump Flowchart 
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PTS-100 DISK DUMP 


BYTE 
0000 
0040 
0080 
0120 
0160 
0200 
0240 
0280 


AAD4C3C9 
D4D3ADB1 
AAC5C9D4 
C8C5A0D3 
AACFD2A0 
C5CTIC9CE 
AACID2C5 
CCC5D4D9 


D3A0C9D3 
BOBOAOC4 
C8C5D2A0 


C5D2C9CI1 


COSCED4C9 
CEC9CECT 
C1 AOQD4CF 
DOC5ACAO 


PTS-100 DISK DUMP 


BYTE 


OCOO 
0080 
0160 
0240 


*THIS IS 


*EITTHER 


*OR ENTI 
*AREA TO 


A SAMPL 
IN HEXAD 
RE SECTO 

BE DUMP 


HEX EXAMPLE 


CYLINDER 0050 TRACK O- SECTOR 


AOCIAOD3 
C9D3C3A0 
COCEAOC8 
CCAOD OD2 
D2C5A90D3 
AOCICEC4 
AOC2C5A0 
C9OCEAOD4 


Figure 3-1l. 


Ci CDDOCC 


C4D5CDDO. 


C5D8C1C4 
COCED4C5 
C5C3D4CF 
AOC5CEC4 
C4D5CDDO 
C8C5A0C6 


ASCII EXAMPLE 


CYLINDER 0050 


E OF THE 
ECIMAL Q 
RS CAN B 
ED ARs: — 


QUT PUT 


R IN ASC 
c& DUMPED 
NTr:RED Q 


C5A0CFC6 
AEAOAOC9 


C5C3C9CD 


D2AEAOAO 
Y2D3A0C3 


COCECTAO. 


C5C4A0CI 
CFD2CDAO 


AQD4C8C5 


D4A0C3C1I 


Cl CCAOCF 
DOC 1D2D4 
CICEAOC2 
€£1C4C4D2 
D2C5A0C5 
C3D9 CCC9 


TRACK O SECTOR 


OF THE P TS-100 D 


Il, ON T 
« HE B 
No THE TE 


HE SERIA 
EGINNING 
LETYPE, 


0000 


AOCFD5D4 
CEAOC2C5 
D2AOC9CE 
C9CI CCAO 
C5A0C4D5 
C5D3D3C5 
CED4C5D2 
CEC4C5D2 


0090 


ISc DUMP 
L PRINTE 
AND END 
IN THE F 


Figure 3-12. Disc Dump Listing in ASCII Code 


JOD5D4A0 
AOCCC9D3 
AOCID3C3 
D3C5C3D4 
CDDOC5C4 
D3AO0CFC6 
C5C4A0CF 
AFD4D2C1 


Disc Dump Listing in Hexadecimal Notation 


- IT CA 
Re PART 
ING ADDR 
ORM CYLI 


CFC6A0D4 
D4C5C4A0 
C9OC9ACAO 
CFD2D3A0 
AEAOAOD4 
AOD4C8C5 
CEAOD4C8 
C3CBAFD3 


N BE LIS 
TAL“SECT 
‘ESSES OF 
NDER/TRA 


C8C5A0D0 
AOAOAOAO 
CFCEAOD4 
AOAOAOAO 
C8C5A0C2 
AOAOAOAO 
C5A0D4C5 
C5C3D4CF 


TED 

QRS 
THE 

CK/SECTO 


Teds 


1 Disc Dump Program Assumptions 


The PTS-100 Disc Dump program assumes: 
Discs with two tracks per cylinder. 

The ''dump to'' address is greater than or 
If this 


is not true, the program will dump to the end 
of the disc. 


The user always responds to the IDENTIFICA- 


equal to the ''dump from" address. 


TION request by typing any 20 characters on 
the display or teletype keyboard. 


-2 Input to the Disc Dumping Process 


After loading the Disc Dump program, if the 


display keyboard is going to be used to input 


directives the following sequence must take place: 


l. User strikes any key on the display key- 


board to be used to input the directives. 


2. The display reads: 
CHARS PER LINE/NO OF LINES 99/99= 
3. User responds by typing a two-digit deci- 


mal number representing the number of 
characters on one line of the display, 
followed by another two-digit decimal 
number representing the number of lines 


on the display. 


When the teletypewriter is used for input 


the process begins with step 4. 


4. The Disc Dump program issues seven 
messages to the display or teletype, each 
expecting a response. The sequence of 

messages and permissible response 


directives are as follows: 
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Program Message 


DEVICE ADDRESS = 


FROM CYLINDER 
TRACK SECTOR 
999/99/99 = 


TO CYLINDER 
TRACK SECTOR 
999/99/99 = 


HEX/ASCIL = 


PARTIAL SECTOR 
999 OR ALL = 


IDENTIFICATION = 


User Types Reply 


one-digit drive address 
(0-7) 


cylinder, track, and 
sector data (in format 
indicated) of dump start 
location; leading zeros 
required 


cylinder, track, and 
sector data (in format in- 
dicated) of dump end 
location; leading zeros 
required 


HEX for hexadecimal 
output, or ASC for 
ASCII output 


three-digit byte count 
for partial sector dump; 
or ALL for full record 
dump 


20 characters to appear 

in the heading of the dump 
for identification purposes; 
any character is allowed 


After the user has typed 20 characters 
following the IDENTIFICATION message, the disc 
will be dumped as directed. At the completion of 


the dump, the following message will be written 


on the teletype or display: 


Program Message 
END OF DUMP ? = 


User Types Repl 


Y will terminate the Disc 
Dump program. 

N will call up the first 
message listed above and 
reenter the dump cycle. 


If the user types an invalid reply to any pro- 


gram message, the message is reissued. The 


display version of the disc dump can be termin- 


ated at any point by depressing the CANCEL key. 


7.3.3 Disc Dump Output 


The Disc Dump program generates three 
types of print lines on the listing. As shown in 
Figures 3-1ll and 3-12, the first print line is the 
header, which appears once; this is the 20 char- 
acters that the user typed in reply to the 
IDENTIFICATION message. 


print line has the format: 


The second type of 


BYTE CYLINDER TRACK 


and appears for each disc sector dumped, indicat- 
ing the cylinder, track, and sector numbers. 
BYTE is the heading for a byte number, which 
will be the left-most entry on each following de- 


tail print line. 


The third type of print line is the detail line, 
containing the dumped data. Four or eight de- 


_ tail lines will be printed per sector, depending 


SECTOR 


on whether hexadecimal or ASCII representation 
was specified. Eight lines will be printed for 
hexadecimal notation, and four lines for ASCII 
code. Each line will begin with the byte number 
of the first byte to be printed on the line, followed 
by 80 printed characters. (For hexadecimal 
notation the byte numbers on the eight lines will 
be 0, 40, 80, 120, 160, 200, 240, and 280; for 
ASCII code the byte numbers will be 0, 80, 160, 


and 240.) Format of the detail lines is as follows: 
9999% XXXXXKXK XXXXXKXK XXXXXXXX- oo 


Padding characters (X'00') within a sector will be 
suppressed from the printout when full sectors 


are being dumped. 


“Byte number of the first byte of the follow- 
ing printed characters. 
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Section 8. 


This program provides a method of storing 
on, deleting, copying, positioning, and printing 


the contents of cassette magnetic tape files. 


The Cassette Utility program may be directed 


to perform the following functions: 


* Copy all or parts of one cassette magnetic 
tape to another. 


® Forward or backspace one tape a specified 
number of records. 


e Position a cassette tape to a specific record 
located by matching a keyword. 


® Rewind a tape to its beginning. 


a Print a specified number of records from 
one tape. 


@ Read cards from the card reader and write 
information to a tape. 


© Print the input directives. 


The input directives can be keyed on any 
2260 display keyboard, but all inputs must be 


keyed from the same one. 


DISPLAY 
KEYBOARD 


CASSETTE 


UTILITY 


PROGRAM 


CARD 
READER 
(OPTIONAL) 


TELETYPE 
PRINTER 
(OPTIONAL) 


Figure 3-i3. 


CASSETTE UTILITY PROGRAM 


The Cassette Utility program requires the 
IOCS monitor for all input and output data and 


device assignments. Peripheral devices that 


may be called by the program include: 


Logical Name Description 


SYSD (LUN3) Card reader. Used to read in 
cards as requested by a Write 
directive (see subsection 8.2.6). 
SYST (LUNS5) Serial printer. Used option- 
ally to print directives and 
for Edit function printing (see 
subsection 8.2.2). 

SYSO 


(LUN6) Display keyboard. Used to 


enter directives. 
LOG8& (LUN8) Magnetic tape cassette for 
performing the requested 
Operation. 
LOGY (LUN) Teletypewriter printer. Used 
optionally to print directives 
and for Edit function printing 


(see subsection 8.2.2). 


The system flow is shown in Figure 3-13. 


DISPLAY 


SCREEN 


TAPE | 
CASSETTES 


SERIAL 
PRINTER 


(OPTIONAL) 


Cassette Utility Program Flowchart 


8.1 Input and Output Devices 


This program can have three types of inputs: 
input directives keyed by the operator on the dis- 
ply keyboard, one of four cassette files, and 
optionally the card reader (for the read-to-tape 
function), Output will be to one of four cassette 
files and optionally to the teletypewriter and/or 
serial printers if printout is requested of the 


directives or files. 


8.2 Operator Input 


The Cassette Utility program is loaded using 
the Absolute/Relocating Loader program. After 
loading, the operator activates the program by 
striking any key on any of the display keyboards 
connected to the PTS-100 system. The message 
NC/CPL/DO/LO will then appear on the display 


associated with the keyboard in use. 


The operator should respond on the same 
Keyboard by keying the following hexadecimal 
information (using the symbol / as a separator): 


Message Decimal Hexadecimal 
Number of characters 480 IE0 
on screen (NC) 960 300 

1920 780 
. Characters per 40 28 
line (CPL) 64 40 
80 50 | 
Device on which keyed 
directives are to be 
listed (DO): 
no listing 00 
serial printer 05 
teletype | 7 _  . 09 
Device on which file 
records are to be 
printed as output of 
Edit function (LO) 
no listing _ 00 
serial printer 05 
teletype 09 


These must be followed by the ENTER key, 
signifying end ofmessage. A typical operator 
response to NC/CPL/DO/LO might be: 


300/40/09/05 ENTER 


signifying a 960 character screen, 40 characters 


per line, printout of keyed directives on the tele- 


typewriter, and printout of the file records on the 


serial printer. 


The program then displays on the screen the 
following listing of functions, their command 


formats, and the request for input. 


FUNCTION COMMAND 
COPY C/F/T/NNNN 
EDIT E/#/NNNN/M 
FORWARD SPACE F/#/NNNN 
BACKSPACE B/#/NNNN 
REWIND | — R/#- | 
WRITE W/#/M 
SEARCH S/#/SSSS/VVVV 
REQUEST? 


The operator responses are described in detail 
in the following subsections. He must depress 
the ENTER key to indicate end of message. He 
may also use the backspace and forwardspace 

keys to edit his input before entering it. Depress- 
ing the CANCEL key will terminate the function 


at the end of the next cassette Read operation. 


8.2.1 Copy Function 


The Copy function is used to copy one 
cassette tape to another. No rewind of either 
tape is performed. Therefore the tapes must be 
positioned (using Forward Space, Backspace, 
Rewind, or Search functions) previous to the 


Copy function. The keyboard entries necessary 


for this function are: 


C/F/T/NNNN 
where 


CG = Copy function 


F = "from!'' cassette drive number (0, 1, 2 
or 3) 
T = ''to'' cassette drive number (0, 1,2 or 3) 


NNNN = number of records. 


The Copy function will stop when it has copied 
NNNN records or it encounters 1EOF in positions 
1 through 4 of a record, on the "from" tape; the 
LEOF will be copied to the "ton tape. 


8.2.2 Edit Function 


The Edit function is used to print a specified 
number of records from any one of four cassette 
tape units on a serial printer or teletypewriter 
printer. 
ASCII code. 


this function are: 


The printout thay be hexadecimal or in 


The keyboard entries necessary for 


E/#/NNNN/M 
where 
EK = Edit function 
# = cassette drive number (0,1,2, or 3) 
NNNN = number of records 
M = mode (H = hexadecimal, A =: ASCII) 


The printed output will include the tape record 


number of the record being printed. 


8.2.3 Forward Space Function 

The Forward Space function is used to 
position any cassette tape forward a specified 
number of records. The keyboard entries 


necessary for this function are: 


F /#/NNNN 
where 
F = Forward Space function 
# = cassette drive number (0,1,2, or 3) 
NNNN = number of records 
8.2.4 Backspace Function 


The Backspace function is used to position 
any cassette tape backward a specified number 
of records. The keyboard entries necessary for 


this function are: 


B/#/NNNN 


where 

B = Backspace function 

# = cassette drive number (0,1,2, or 3) 
NNNN = number of records 
8.2.5 Rewind Function 


The Rewind function is used to position any 
cassette tape to its beginning. The keyboard 


entries necessary for this function are: 


R/# 
where 
R = Rewind function 
# = cassette drive number (0,1,2, or 3) 
8.2.6 Write Function 


The Write function is used to read either 
Hollerith or binary information from punched 
cards and to write the information unblocked onto 
any magnetic tape cassette unit. The keyboard 


entries necessary for this function are: 


W/#/M 
where 
W = Write function 
# = cassette drive number (0,1,2, or 3) 
M = mode (H = Hollerith, B = binary) 


The Write operation begins with the first card 
read. The end of file card for Hollerith has 
1EOF punched in columns 1 through 4; lEOF is 
The end of file card for 


binary has a 2-7-8-9 punch in column 1; this is 


copied onto the tape. 


not written to the tape. 


8.2.7 Search Function 


The Search function is used to position a 


cassette tape at a certain record. The program 


reads the tape until it encounters a specified key. 


The keyboard entries necessary for this function 


are: 
$/#/SSSS/VVVV 
where 
S = Search function 
# = cassette drive number (0,1,2, or 3) 
SSSS = starting position of the key in hex 
(0000 is the first position in the 
record) 
VVVV = value of the key in ASCII (up to 15 


characters long) 


If 1EOF is read on the tape before the key is 
found, the message NOT FOUND will be dis- 


_ played on the screen. 
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8.3 Error Messages 


If the keyed function cannot be completed, 


one of the following error messages will be dis- 


played: 
Error Message 


READ ERROR 
CASSETTE NOT 
OPERATIONAL 


KS NOT 
OPERATIONAL 


SP NOT 
OPERA TIONA L 


CRNOT | 
OPERATIONAL 


END OF TAPE 
KEYBOARD ERROR 


NOT FOUND 


Meaning 


Unable to read cassette 
record. 


Cassette tape not in drive, 
or cassette not working. 


Teletypewriter printer not 
working. 


Serial printer not working. 
Card reader not working. 


Have reached end of tape. 
Keyboard not working. 


On search, value was not 
found. 


‘Absolute/relocating loader 
error listing 
input 
output 
symbol map 
ACIC directive 
ASGL directive 
ASGP directive 


CALL directive 
Cassette utility program 


Correct program director (${CORP) 


Data line directors 
Debug, interactive 
commands 
addition 
alter 
backspace 
breakpoint 
cancel record 
clear breakpoint 
computational 
dump 
editing 
fill 
go to 
memory value access 
proceed 
search 
set breakpoint 
subtract 
error messages 
input 
loading 
Delete data line director ($DEL) 
Delete program director ($DE LP) 
Disc allocator program 
Disc dump program 
Disc volume preparation program 
Dump program 


disc 


END directive 
END director (SEND) 
EOF director ($EOF) 
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calling sequence 
input parameters 
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Section l. 


The System Macro Library file is a collec- 
tion of all the generalized, source-coded 
routines used to create a user- specialized Input/ 
Output Control System (IOCS) monitor. That is, 
the System Macro Library file contains all of the 
optional and standard routines that may be in- 
corporated into an IOCS monitor to be created 
for any given user of a PTS-100. Any routine 
on the System Macro Library file may be called 
by the System Generator (SYSGEN) program, 
which generates macro call statements accord- 
The 


SYSGEN macro call statements are written onto 


ing to user-specified system descriptions. 


an Assembler-formatted file, which is input, 

along with the System Macro Library file, toa 
PTS-100 Assembler run, and processed by the 
macro processor phase to produce specialized 


IOCS monitor routines. 


Presented on the following pages are de- 
tailed descriptions of the macro routines com- 
prising the IOCS monitor, and the manner in 
which they are specialized to create a unique 
version of the monitor. The purpose of these 
descriptions is to indicate to the user the intri- 
cate relationship and structure of the various 
parts of the monitor and the technical require- 
ments that must be met if additions or altera- 


tions are to be made to the IOCS monitor 


supplied by Raytheon Data Systems. 


1,1 System Cells Macro Routine (#IMSCP) 


This macro routine causes the IOCS moni- 
tor's global communications (system cell) area 
to be initialized in decimal locations 0-127. 
That is, it sets up the cross- reference area via 
which routines within the monitor can be 
accessed by other monitor routines. Specifically, 


this routine establishes the origin of the monitor 
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PTS-100 MACRO LIBRARY FILES 


SYSTEM MACRO LIBRARY FILE 


at location 0, reserves communications areas, 
identifies symbols used in monitor routines 
other than itself, and assigns the addresses of 
all monitor service routines, some of which are 
OPEN LUN, CLOSE LUN, EXIT, INITialization, 
and IOACT. The system cells routine is always 
called by the SYSGEN program, which generates 
the call 


$A\ #IMSCP 


Since there is no actual argument list supplied in 
this macro call, and no dummy arguments in the 
routine, the entire #IMSCP routine is incorpo- 


rated in the IOCS monitor being generated. 


I.2 Interrupt Packet Initialization Macro 
Routine (#IMIP) 


‘This macro routine is called by the SYSGEN 
program to effect the creation of the interrupt 
packets of the IOCS monitor. The routine con- 
tains specialized coding for interrupt packets 
for interrupt levels 0 and 9, and generalized 
coding for the packets of the external interrupt 
levels | - 8 and the parity interrupt level 10, as 


shown in Figure 4-1. 
Notice that the generalized coding for the 
interrupt packets contain dummy arguments in 


the form 


a ee 00 


This type of dummy argument specifies that the 
macro routine statement in which it appears is 
to be omitted from the specialized routine if the 
nth actual argument inthe associated macro call 
statement is equal (E) or not equal (N) to the 
value 00. The associated macro call generated 


by the SYSGEN program is shown below: 


?#IMIP 

ete We tee te tee ee ee ee ek i ke te te a RK KKERE RE KHER KKK 
Wee te he te ie te te ek tee We ek tee ee a a REE AAK KEENE KKK 
* ; 

* - INTERRUPT PACKETS . 

* 

hehehe eee eee ee eee PPP SECS SCS SSCL SCLLOS SSCS SCS Te TST TTT LTT TTT TTT 
Wee We ee te ee tek ee ee eee tee ee ie ee eee ee de a RK EK EKER KHEKM EERE KEE 


* 
* 


RFSV,2 


#ITIPOA 2 OLD PC FOR LEVEL @ 
RESV,A 2 OLD LEVEL AND CB 
ANC #IYCLK CLOCK SERVICE ROUTINE 
INR INTFRRUPT RETURN 
* 
HITIP1 RFSV,a 2 OLD PC FOR LEVEL 1 
RESV,@ 2 OLD LEVEL AND CB 
ANC #IXSR1 LEVFL 1 SERVICE ROUTINE (1,E,90) 
ADC #49 IGNARE INTERRUPT (1,N,0A) 
INR INTFRRUPT RETURN 
* 
HITIP2 RESV,a 2 OLN PC FOR LEVEL 2 
RFSV,A 2 OLM LEVEL AND CB 
ANC #IXSR2 LEVFL 2 SERVICE ROUTINE (2,E,00) 
ADC *+2 IGNORE INTERRUPT (2,N,00) 
INR INTERRUPT RETURN 
: | 
#ITIP3 RESV,@ 2 MLN PC FOR LEVEL 3 
RESV,A 2 OLN LEVEL AND CR 
ADC #IXSR3 LEVFL 3 SERVICF ROUTINE (3,E,00) - 
ADC *+2 IGNORE INTERRUPT (3,N,Ua) 
INR -INTERRUPT RETURN 
¥* 
HITIP4 RFESV,@ 2 OLN PC FOR LEVEL 4 
RESV,A 2 OLN LEVEL AND CR 
ANC HIXSR4 LEVFL 4 SERVICE ROUTINE (4,E,08) 
ADC *+2 IGNORE INTERRUPT _ (4,N,00) 
INR oe INTERRUPT RETURN 
¥® 
#ITIP5 RESV,A@ 2 OLD PC FOR LEVEL 5 
RFSV,@ 2 OLD LEVEL AND CR 
ANC #IXSR5 LEVFL 5 SERVICE ROUTINE (5,E,00) 
ANC “+2 IGNORE INTERRUPT (5,N,00) 
INR INTERRUPT RETURN 
* 
HITIP6 RESV,& 2 NLP PC FOR LEVEL 6 
RESV,A 2 OLD LEVEL AND C8 
ADC #HIXSRE LEVEL 6 SERVICE ROUTINE (6,E,@0). 
ADC &+2 IGNORE INTERRUPT (6,N,@0) 
INR INTERRUPT RETURN 
* 
#ITIP7 RESV,@ 2 OLD PC FOR LEVEL 7 
RESV,A 2 OLO LEVEL AND CB 
ADC #IXSR7 LEVFL 7 SERVICE ROUTINE (7,£,@0) 
ADC *+2 IGNORE INTERRUPT (7,N,AQ) 
INR INTERRUPT RETURN 
* 2 
#ITIPB RESV,@ 2 OLD PC FOR LEVEL 8 
RESV,@ 2 OLD LEVEL AND CB_ | 
ADC #IXSRB LEVEL & SERVICE ROUTINE (8,E,0A) 
ADC #42 IGNORE INTERRUPT (8/N,90) 
INR INTERRUPT RETURN | 
® 
#ITIP9 RESV,W D>» . @LB PC FOR LEVEL 9 CCT 
_ _ RESV,® 2) OLD LEVEL AND CB 
ADC #IUMSC MONITOR SERVICE CALL ROUTINE 
ee __RESV,»8 2 sep Eo, os ate een ctanewh eo. Ripdineites wis ale Dida, ot 
* 
WITIPA RESV,® 2 OLD PC FOR LEVEL 10 = 
RESV,@ 2 OLD LEVEL AND CB 
ADC #IVPAR PARITY ERROR RETURN  —s— (41M, E, 86) 
ADC wee EGNORE INTERRUPT (14,N,9@) 
eee eee | eee nie NTE RRUP TY RETIN oie dei eli oes ae 
Si Oe PE 
END 


Figure 4-1, Generalized Coding of the Interrupt Packet Initialization Routine 
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$a #IMIP a Arg), Arg,,Arg,,Argy, Arg, Argy, Arg., Arge, 00, Argig 


The actual arguments, Arg, through ATS) os 
correspond to the interrupt levels 1 through 10. 
That is, the first argument in the list pertains to 
external interrupt level 1, the second to interrupt 
level 2, etc. The 9th argument is a default argu- 
ment to cause an interrupt packet to be generated 
for level 9, the interrupt level at which the 
monitor runs. The level 10 packet is generated 
only if an argument other than 00 appears in 
position 10 of the #IMIP call. 


is generated by SYSGEN to indicate whether or 


The argument list 


not one or more devices have been assigned to 
the interrupt levels, as specified on the ASGP 
directive. Thus, if a device is assigned to 
interrupt level 1, the first argument's value is 
Ol. In this manner, the remaining arguments 
indicate both the level and assignment of devices 
to the level. If no device assignment has been 
specified for a given interrupt level, SYSGEN 
generates an actual argument of 00 for the 


corresponding position of the argument list. 


When the $A#IMIP macro call is processed 
by the Assembler's macro phase, the arguments 
are read and inserted in a table in the order of 
The #IMIP macro 


routine is then located in the System Macro 


their appearance in the list. 


Library file and the specialization of the routine 
is performed. The first step in processing is to 
write the coding for the level 0 interrupt packet 
onto the IOCS output file. The coding for packet 
l is then read. The first two statements are 
The third statement 
To 


specialize this statement, the processor com- 


written onto the output file. 


contains the dummy argument (1, E, 00). 


pares argument 1 in the argument table with the 
specified value 00. If the two values are equal, 
the ADC statement is omitted from the special- 
ized interrupt packet. That is, if the argument 
value is 00, no device has been assigned to this 
interrupt level, hence no service routine will 

be generated for the interrupt level. Statement 
4 in the packet coding contains the dummy argu- 


ment (1,N,00). When the statement is selected 


for processing, the actual argument 1 is com- 
pared to 00, and if they are not equal the state- 
ment is omitted from the interrupt packet coding 
that is written onto the output file for the IOCS 
monitor being created. Thus, the coding of 
interrupt packets 1 through 8 specifies that either 
statement 3 or 4, but not both, is to be included 
in the specialized coding, depending on whether 


or not a device assignment has been specified 


for the corresponding interrupt level. 


The interrupt packet for level 9 contains no 
dummy arguments, and is therefore written onto 


the output file of the monitor. 


The interrupt packet for level 10 is special- 
ized with the address constant statement assign- 
ing the address of the parity routine if the value 
of actual argument 10 in the macro call state- 
The value of actual 
argument 10 is assigned in the SYSGEN CALL 


directive which specifies the optional Parity 


ment is other than 00, 


Error Routine, as described in subsection 1. 20. 


1.3 Logical IO Control Table Macro Routine 


(#IMCTL) 


The IO Control Table (IOCT) of the IOCS 
monitor consists of two parts: the logical-to- 
physical device pointers and the Physical Control 
Blocks (PCBs). 
portion of the table is created by the Assembler 
The 


logical-to-physical pointers portion of the IOCT 


The logical-to- physical pointers 


via specialization of this macro routine. 


will contain 13 one- word entries containing the 
logical unit name, the identifier of the physical 
unit assigned to the logical unit, and the logical 
unit number (LUN) of that particular device. 

That is, for any given IOCS monitor, 13 logical 


units may be assigned to actual physical devices. — 


Eight logical units may be assigned for the use of 
systems programs (e.g., the Assembler, the 
loaders, the debug and dump programs, etc.). 
Five logical units may be assigned for use of 


applications programs. The names of the 


system-reserved logical units begin with the . 
characters #ISYS, followed by an additional 
character which denotes the use of the unit by 
systems programs. The names of logical units 
that may be assigned for applications programs 
begin with the characters #ILOG. The logical- 
to- physical pointers are developed from user- 
specified physical device identifiers on the ASGL 
directive in the SYSGEN input deck. That is, 

the ASGL directive may assign from one to 13 
devices to logical units by entering the device 
identifiers in the order in which they are to be 
assigned to logical units inthe IOCT. If no 
physical device is to be assigned to a logical 
unit, the user indicates the omission by three 
zeros in the corresponding position on the ASGL 
directive. When the SYSGEN program analyzes 
the ASGL directive, a macro call is generated in 
the format: 


$A #IMCTLAD,,D,,D 


|? 2° zreeeeD 


13 


where the Ds are device identifiers, described 


P#IMCTL 


in the detailed discussion of the-PCBs in the 


following subsection. 


~ When the Assembler macro processor en- 
counters the $4 #IMCLT macro call, it con- 
structs an argument table, enters the D 
arguments in the table in the order in which they 
appear in the call statement list, locates the 
#IMCLT macro routine on the System Macro 
Library file, and specializes the IOCT logical- 
to- physical pointers by inserting the table entries 
in the corresponding dummy argument positions 
in the generalized #IMCTL routine, shown in 


Figure 4-2. 


The second portion of the IOCT, the Physical 
Control Blocks, is generated from the general- 
ized #IMCTP macro routine, described in the 
following subsection. Notice that the specialized 
#IT(n) address constant becomes the label of the 


corresponding PCB for the assigned device. 
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PGA #ITANGA 
#I1TMMA EAU  #TAARS 
#ISCTL EAU * 
#ISYSF ADC #I1T(1) SYSTEM FILE 
HISYSI ANC #IT(?) SYSTEM INPUT 
#ISYSL ANC ~—#IT(3) SYSTEM LOG 
HISYSD ANC #1T(4) SYSTEM DATA 
#ISYSB ANC #IT(5) BINARY INPUT 
HISYST ADC HI T(6) LISTING | . a 
HISYSO ANC #IT(7) SYSTEM OUTPUT 
#ISYSR ANC #1T(8) SCRATCH 7 
#ILOG8 ANC #IT(9) LOGICAL UNIT 8 
HILOGO ANC #IT(10) LOGICAL UNIT 9 
HILOGA ANC #I1T(11) LOGICAL UNIT A 
#ILOGB ANC #IT(12) LOGICAL UNIT BB a 
#ILOGC ANC #I7T(13) LOGICAL UNIT C. 
SKIP p 
FND 


Figure 4-2. Generalized Coding of the #IMCTL Routine © 


1,4 Physical Control Block Macro Routine 


(#IMCTP) 


The Physical Control Blocks (PCBs) form 
the second portion of the Input/Output Control 
Table in the IOCS monitor. The PCBs are 
seven- word tables that specify the necessary 
information to control the physical devices 
within the equipment configuration. That is, a 
PCB is created for each device to be serviced 


by the monitor. 


The information for each PCB is specified 
in sets of parameters on the ASGP directive 
that is input to SYSGEN. Each set of parameters 


is specified as follows: 
DID, DAD, DIL, DSC, DIM, SEN 
where: 
DID is one of the following: 


® the device identifier if this is the only 
device of this type to be attached toa 


multiplex controller. 
@ the first of a group of identical devices. 


e a comma if more than one device of this 
type is attached to a given multiplex con- 
troller, as specified by the DIM para- 


meter in position 5 of the parameter set. 


DAD is the device hardware address of the 


assigned device. 


DIL is the external interrupt level | through 


8 to which the device is being assigned. 


DSC is a two-character code to be used to 


effect the unique identification of the partic- 


ular device's Physical Input/Output Table 
(PIOT). 


DIM is one of the following: 


a comma if the DID parameter specifies 


a device identifier 


the multiplexed device identifier if DID 
is a comma, indicating that two or more 
devices of the same type are attached 


to a given multiplex controller 


SEN is a sentinel specified as one of the 


following: 


a comma if the DIM parameter is a 
comma or if this is not the last device 
of the same type to be attached toa 


given multiplex controller 


an L to indicate that the device identified 
by the DIM parameter just preceding is 
the last device of its type attached to a 


given multiplex controller. 


For each parameter set specified on the 
ASGP directive, the SYSGEN program generates 
a macro call with the parameter set as its 


argument list, as shown below: 
$A #IMCTPA DID, DAD, DIL, DSC, DIM, SEN 


At assembly time, the macro processor 
constructs an argument table for the $A #IMCTP 
argument list, locates the #IMCTP macro 
routine on the System Macro Library file, and 
inserts the arguments for each device in place 
of dummy arguments in the PCB generalized 
That is, a PCB is 


created for each device assigned on the ASGP 


macro routine, shown below. 


directive. 


2#IMCTP 
* 


teewe=-PHYSICAL CONTROL RLOCKS 


* 


#ITC1) HFX (3) CiN) 
HEX (3) (1Y) 
HE xX 1(2) NEVICE ADDRESS 
ANC #IN¢1) NEVICE DRIVER (1N) 
ANC . #1IN(5) NEVICE DRIVER (1Y) 
RESV,A 4 TOCQ CONTROL 
ANC HITP(4) PINT ADDRESS 
RFSV,A 2 SPARE (6Y) 
HE X FFFF MPX SENTINEL (6N) 


ENN 


Notice that if the DID parameter is specified, 
the first HEX statement of the generalized rou- 
tine is specialized with the DID completing the 
label and the interrupt level (DIL) completing the. 


operand field. 


If DID is not specified, the first HEX state- 
ment is omitted from the routine and the 
interrupt level is entered as the operand field of 
the second HEX statement. In all cases, the 
DAD parameter must appear and is inserted to 
complete the operand field of the third HEX 


statem ent. 


The first ADC statement operand is com- 
pleted with the DID value, if specified. If it is 
not specified, the statement is omitted from the 
specialized routine. The second ADC statement 
is specialized if the first ADC statement is 
omitted. That is, if the DID parameter is not 
specified, the DIM parameter must be specified 
and is used to complete the multiplexed Device 


Driver Routine address. 


The PIOT address in the last ADC statement 
If the 
SEN parameter is specified, the last RESV 


is specialized with the DSC parameter. 


statement is omitted from the specialized rou- 
tine and the last HEX statement is included. If 
the SEN parameter is not specified, the last 
RESV statement is included and the following 


HEX statement is omitted when the specialized 


coding is written by the Assembler. 


1.5 Channel Interface Control Block Macro 


Routine (#IMCCB) 


The #IMCCB macro routine is called once 
for each device assigned to the Channel Interface 
Controller via the ACIC directive input to SYS- 


GEN. Each macro call is in the format: 
$A #IMCCBA TAG, CAD, PDAD 
where: 


TAB is the symbolic tag to be assigned to 
the starting location of the CCB for each 


assigned device. 
CAD is the channel address of the device. 


PDAD is the physical address of a specific 
device within a group of devices attached to 


a channel, 


At assembly time, the #IMCCB routine is 
called and a channel control block (CCB) is 
specialized for each device by replacing the 
dummy arguments with the actual arguments in 
the SYSGEN macro call. 


of the #IMCCB macro routine is as follows: 


The generalized coding 


?H#IMCCB 


we CIC DEVICF 

* 

H#ITC(1) HE x 0 
HE X 1(2) 
ANC #INDCTA 
RESV,@A 4 
ANC #ITN(1) 
HF X A(3) 
END 


Notice that the first actual argument is used 
to specialize the label of the CCB and also to 
specialize the address constant #ITD(1) for the 
associated device packet. That is, a device 
De- 
vice packets are created by specialization of the 
#IMCDP macro routine for which SYSGEN gen- 


erates the call 


packet is created for each assigned device. 


$A #IMCDPA nn, T 
where: 


nn is the total number of devices attached to 
the CIC (i.e., 16, 32,48, or 64), 


T specifies the tumble table to be used. 


For each device specified by nn, a 16-byte 
device packet is created at assembly time. The 
generalized coding of the #IMCDP routine is 


shown in Figure 4-3. 


The T argument is used to specialize the 
first statement in the #IMCDP routine. This 


first statement is the macro call statement: 


$A #IMCT (2) 


which causes interrupt tumble tables to be 
created for use of the CIC. There are two 
macro routines which define interrupt tumble 
tables within the System Macro Library file: 
the prototype CIC interrupt tumble table routine 
(#IMCT1) and the production CIC interrupt 
tumble table routine (#IMCT2). The prototype 
routine will be called and inserted in the IOCS 
monitor being created if the actual value of the 


T argument is 1, and the production routine will 


CHANNEL, 
CIC DEVICE DRIVER 
TOCA CONTROL 
PACKET ADDRESS 
NEVICE ADDRESS 


ANDRESS 


be called and inserted if the actual value of T is 
2. The generalized coding of the #IMCT1 and 
#IMCT2 routines is shown in Figure 4-4. 


1,6 Logical Unit Assignment Macro Routine 


(#IMLAS) 


This macro routine contains only comments, 
and provides user documentation of the logical 
unit assignments within his particular version of 
the IOCS monitor. The coding of the #IMLAS 
macro routine is shown in Figure 4-5. At 
SYSGEN time, the tags of the Physical Control 
Blocks (PCBs) of the assigned logical units are 
inserted in the place of the associated dummy 
arguments in the comments of the form 

*# IT (nn) EQU 


operand value (nN) 


if a logical unit has been assigned. 
The #IMLAS comments are printed by the 


SYSGEN program. 


corporated in the assembly- formatted file. 


They are not, however, in- 


It is the responsibility of the programer to de- 
termine the LUN assignments from the docu- 


mentation of his particular IOCS monitor. 


1.7 Physical Input/Output Table Macro Routine 
(#IM PIT) 


This routine is used to create a Physical 
Input/Output Table (PIOT) area for each device 
assigned on the ASCP directive input to SYSGEN. 
That is, the fourth parameter, DSC, in each set 
of ASGP parameters is used to specialize the 


beginning address (i. e., the label) of the PIOT 


?4IMCDP 
$ RIMCT(2)) (1) 


Week eh et ke ae ee ee Ee REE HEKKEEEKEKEEKKEEKEKEE 
WHERE K KEKE KKK Ka KKH K a K KKK KKK KKEKHR EKER 


* 


* 


Wee We te te ete te te te te te ete te KEK TREK EK KEK KKEKEKEKRNKERKREK 
Wee ee ee ke tek ek ed ERE ERE K KEKE HKEKKKK KKK Kee 


* 
* 
* 


* CIC DEVICE PACKETS 


sean: AO eS 


MND 256 | 
HITDUA RESV,A 16 DEVICE PACKET 
EXDEF #1TDAG 
H#ITDG1 RESV,A 16 NEVICE PACKET 
EXDFF #ITDAL | 
#ITD@2 = RESV,A~A 16 DEVICE PACKET 
EXDEF #I1TDAD 
#ITNY3 RESV,A° 16 DEVICE PACKET : 
EXDEF #HITDAZ 
#ITDQ4 RESV,A 16 DEVICE PACKET 
; EXDEF HITOAG 
HITNQS5S RESV,o 16 DEVICE PACKET § 
EXDFF #ITDAS 
#I1TD@6 RFSV,4“ 16 DEVICE PACKET 
EXDEF #I1TDA6 
#ITDQ7 = RESV,@ 16 NEVICE PACKET 
EXDEF #1 TDA7 
#ITNDQ8- RESV,aA 16 NEVICE PACKET 
EXDEF #1 TDAB 
#ITNG@9 RESV,aA 16 DEVICE PACKET 
EXDEF #ITDAQ . 
HITDQA RESV,A 16 DEVICE PACKET 
EXDEF HITDOA 
#ITDOR RESV,aA 16 DEVICE PACKET 
EXDEF —#1TDAB 
#ITDG@C RESV,A 16 NEVICE PACKET 
~ EXDFF #ITDAC 
HITDAD RESV,A 16 DEVICE PACKET 
EXDEF HITDAD 
H#ITDGE RFESV,@A 16 DEVICE PACKET 
EXDEF #HITDAE 
HITDO@F RESV,@ 16 NEVICE PACKET 
oe  ™"EXOEF  Oo#LTDOF . 
* 
HITD1@ RESV,@ 16 DEV PACKET 19 (1,616) 
EXDEF  #ITDi@ | (1,6,16) 
HITD11 RESV,a 16 DEV PACKET 11 (1,&,16) 
| EXDEF #ITDI1 | ed pees (1,6,16) 
“AITD12 RESV,H@ 16° DEV PACKET 12 (1,6716) 
EXDEF #ITD12 | (1,E,16) 
#ITD13 RESV,a@ 16 DEV PACKET 13 (1,6,16) 
EXDEF #ITD13 Oo (1,E,16) 
#I1TD14 RESV,9 16 DEV PACKET 14 (1,E£,16) 
EXDEF HITD1I4 (1,E,16) 
“AITOI5 RESV,H “(6 ~~” “BEV PACKET {5 ~~ (476,16) 
EXDEF #ITOLS Bo es Re eg oe, (1,E,16) 
~#ITO016 RESV,A ~~ 16 ; DEV PACKET 16 (1,616) 
EXDEF #I1T016 2 01,6516) - 
“HITDI7Z RESV,a 16 DEV PACKET 17 (1,6,16) 
ExDEF #1TD17 Awa eass I Ee 16) 
#ITD18 RESV,a 16 DEV PACKET 18 (1,€,16) 
EXDEF #ITD18 re (1,616) 
“#1T019 RESV,9 16 DEV PACKET 19 (1,6,16) 
EXxDEF M1T019 —C4,E, 16) . 
“#ITOYA RESV,o 16 ~~ DEV PACKET 4A (1,6716) 
EXDEF HITDIA (1,E,16) = = 
#ITDiB RESV,a@ 16 ” DEV PACKET 18 (1,E,16) 
EXDEF #1TD1B (1, Ee 16) ~ ; 
“RITDO{C RESV,6 16 °° .  . £4DEV PACKET {€C  — (1,E,16) 
EXDEF #ITDIC - (1,E/16) 
Figure 4-3. Generalized Coding of the #IMCDP Routine (Sheet 1 of 2) 


#ITDIN RESV,a 16 DEV PACKET 1D (1,E,16) 
EXDEF #I1ITNIN (1,E,16) 
#ITDIE “RESV,A {6 DEV PACKET jE (1,€,16) 
EXDEF #ITONIE (1,E716) 
AITONIF RESV,—A 16 DEV PACKET {F (1,616) 
EXDEF #ITDIF (1,E,16) 
HITN2A = RESV,a 16 OP 2a (1,-€,16)(1,E,32) 
EXDEF #I1TD20 (1,E,16)(1,E,32) 
#ITD21 RESV,aA 16 DP 4 (1,€,16)(1,€,32) 
EXDEF #ITO?1{ (1,E,16)(1,E,32) 
HITD22 RESV,@ 16 NP 202 (1,€,16)(1,E,32) 
EXDEF #I1TD22 (1,F,16)(1,E,32) 
#ITN23 RESV,A 16 DP 23 (1,€,16)(1,E,32) 
EXDEF #1 TD23 (1,E,16)(1,E,32) 
HITO24 RESV,aA 16 DP 24 (1,E,16)(1,E€,32) 
EXDEF #ITD24 (1,F,16)(1,E,32) 
HITD25 RESV,a 16 DP 25 (1,E,16)(1,E,32) 
EXDEF #1TD25 (1,E,16)(1,E,32) 
#ITD26 RESV,A 16 DP 26 (1,E,16)(1,E,32) 
EXDEF #1 TD26 (1,E,16)(1,E,32) 
BITOD7 RESV,A 16 NP 27 (1,E,16)(1,E,32) 
EXDEF #ITO27 (1,F,16)(1,E,32) 
#ITD2R RFESV,A 16 OP 2a (1,E,16)(1,E,32) 
EXDEF #I1TD28 (1,E,16)(1,E,32) 
#ITD29 RESV,A 16 NP 29 (1,E,16)(1,€,32) 
EXDEF #ITD29 (1,E£,16)(1,E,32) 
HITD2A RESV,A 16 DP PA (1,6,16)(1,E,32) 
EXDEF #ITD2A (1,E,16)(1,E,32) 
#ITD2R RESV,A 16 NP PR (1,E,16)(€1,€,32) 
EXDEF #1TD2R (1,E,16)(1,E,32) 
HITD2C RESV,@ 16 DP 2¢ (1,€,16)(1,E,32) 
EXDEF #ITD2OC. (1,€6,16)(1,E6,32) 
#ITD2D RESV,A 16 DP 2n (1,E,16)(1,E,32) 
EXDEF #ITN2D (4,€,16)(1,E,32) 
HITD2E RESV,A 16 NP 2E (1,6,16)(1,E,32) 
EXDEF HI TD2E (1,E,16)(1,£,32) 
HITD2F RESV,Q 16 NP 2F (1,F€,16)(1,E,32) 
—— EXDEF HITD2F (1,6,16)(1,E,32) 
HITD3A RESV,A 16 NP 39 (1,£,16)(1,E,32)(1,6,48) 
EXDEF #ITD3Q (1,E,16)(1,E£,32)(1,E,48) © 
#ITO31 RESV,A 16 NP 34 (1,E,16)(1,E,32)(1,€,48) 
EXDEF AITOS31 (1-E,16)(1,E,32)(1,E,48) 
#ITD32 RESV,A 16 DP 32 €1,£,16)(1,E,32)(1,E,48) 
och bE RDEF #1 TD32 | (126,16)(1,F,32) (126, 48) 
#ITD33 RESV,A 16 DP 33 (1,E,16)(1,€,32)(1,6,48) 
EXDEF #ITD33 (1,E£,16)(1,E,32)(1,E, 48) 
#ITD34 RESV,A 16 DP. 34 (1,6,16)(€1,6,32)(1,E,48) 
oe EXDEF #I1TD34 (1/€,16)(1,£,32)(1,E,48) 
RITDI5 RESV,A@ 16 DP 35 (1,6,16)(1,E,32)(1,£,48) 
oan 4°) ig #I1TD35 Wi ee Satoal ~—6C1 2 E169 01,6 2329061,62 48) 
#ITD36 RESV,@ 16 DP 36 (1-E6,16)(1,€,32)(1,E, 48) 
—  EXDEF. #ITD36 (1,-E,16)(1,F,32)(1,E,48) 
#ITD37 RESV,@ 16 DP 37 (1,£,16)(1,£,32)(1,E,48) 
EX DEF #1TD37 (1-E€,16)(1,E£,32)(1,E, 48) 
#ITD38 RESV,@ 16 pp 38 (1,6,16)(1,6,32)(1,E, 48) 
ss EXDEF CU ITO3B UU HE 1671, E,32071,E, 48). 
#ITD39 RESV,@ 16 DP 39 (1,&,16)(1,E,32)(1,E,48) 
ow. EXDEF —) #1ITD39 | a ~—6O107E 416) 01,E,32)(1,E, 48) 
HITD3A RESV,9@ 16 DP 3A (1,6,16)(1,E,32)(1,E,48) 
oi EXDEP  ITDSA iii) Ey 169 01,-E, 32205, E, 48) 
#ITD3B RESV,@ 16 ) DP 3B (1,E,16)(1,E,32)(1,E,48) 
EXDEF #ITTO3B (1,E,16)(1,E,32)(1,E,48) = = 
ZITDOSC RESV,@ 16 DP 3C (1,€,16)(1,E,32)(1,E,48) 
___._. EXDEF  — #ITDIC | i E169 01,E,32)01,E,48) 
ITD3D RESV,-@ 16 DP 3D (1,&,16)(1,E€,32)(1,E,48) 
____EXDEF = #ITD3D = A Ep 16901,E,32901,E, 48) 
 WITD3E RESV,@ 16 DP 3E (1,E,16)(1,E,32)(1,E, 48) 


EXDEF #ITDSE (1,E£,16)(1,E,32)(1,E,48) 


FITD3F RESV,@ 16 DP 3F (1-E,16)(1,E,32)(1,E,48) 
ak _EXDEF  #ITOSF Ey 169 (1,E,32)9(1,E, 48) 
* 
_ ee ee eee ean ne eRe ee eee 
END 


Figure 4-3. Generalized Coding of the #IMCDP Routine (Sheet 2 of 2) 
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2H#IMCTI » 
Se eee eee eee ee ee eee ee ee eee cee ee eee See ee ee eS ee 
TRESTLE TE LTTE TEC EE CCE TT 
ji | 

* INTERRUPT TUMBILF TARLES 

* PROTOTYPE CIC 

Pee eee ee Pe eT eee SSS See eS ee ee eee eee ee ee eT ee ee oe 
Bek eee ee ie kek ek kee kkk kk dk tk IO kk kk ek kk & 


* 
Cees TIMRLF TARLE  § j 
#ITIT RFSV,A 128 INTERRUPT TUMBLE TABLE 4 
EXDFF eITITS 
es | 
* 
sl ore TUMRLE TARLE 2 
MOD 256 | | 
#ITIT2 RFSV,DP 128 TINTEPRUPT TUMBLE TABLE 2 
EXDEF #ITIT? 
: | 
SKIP P. 
END 7 
@HIMCT2 . | 


FR IS IIS I RIOR II IOI TI OI III St IOI IK tte te tet 
Fe te te de te Tt RT Rk ta rR HOS KR dt td TO te 
* : ‘ 
* 7 | INTERRUPT TUMBLE TABLES 

* ar | PRODUCTION CIC 

Fe Te ER I RTO OI IIR IR RII IIE IOS dt koke 
Ke ea KKK KKK KKK KK KKK HK KKK KEKE KHKKEKKEKEKEKK KKK 
é | | 


: : 

eemememeTIIMRLE TABLE 1. 
MND 64 : 

#ITIT1 RESV,A 64 INTFRRUPT TUMBLE TABLE 1 
EXDEF  #ITIT! | 

: | 

: | | 

kewee=TIMRLE TABLE 2 
MOD - 64 

#ITIT2 RFESV,@ 64  — | INTFRRUPT TUMBLE TABLE 2 
EXDEF HITIT2 é 
RESV,A 512 — (1,£,16)(1,E,32). 
SKIP P | | 
END 


Figure 4-4, Generalized Coding of the #IMCT1 and #IMCT2 Routines 
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2HIMLAS 

SKIP p 
We te te te de ete te te te de te te de te te te de ek ete te KEKE KKK EK KEKEKREKEKEKEKKKKEERE 
wow kk et KHER KEMAH KE KKK KEKE KEKE KK KKK KKK KEKE 
| 


* LUN ASSIGNMENTS 
* . 
We Ye te tee tee te ee dete te ike ie tee ek ek te ee ee aK EE KEKEKKEKKAK HK K EK 


eK ete te te te te te te te IKK TT EKER KKK EEK KEM KKK KEKE KE KKK 
* 


*H#ISYSF EAU 


S 


SYSTEM FILE 


*#TSYSI EQU 1 SYSTEM INPLIT 

*#ISYSL EAU 2 SYSTEM LOG 

*#ISYSD EAU 3 SYSTEM DATA 

*#ISYSAR EQU 4 BINARY INPUT 

*#ISYST FAY. 5 LISTING 

*#I1SYSO FQU 6 SYSTEM OUTPUT 

*#ISYSR FAU 7 SCRATCH 

*#ILOG8 EQU Rg LOGICAL UNIT 8 

*A2TLOG9Q ENU 6) LOGICAL UNIT 9 

*e#ILOGA ENMU A LOGICAL UNIT A 

*#TLOGH EAQU B LOGICAL UNIT B 

*#TLOGC EAU - C LOGICAL UNIT C 

*£IT(C1) EQu D C1iN) 
*#1TT(2) EQU “EF C2N) 


*#TT(3) EQU 


n 
cot 
Cal 
Zz 
ww 


*#1T(4) EQu 1A a (4N) 
*#TT(5) ENU 11 (5N) 
*#1IT(6) EAU 12 | (6N) 
*#1T(7) EQU 13 (7N) 
*#TTC&8) ERU 14 C8N) 
*HEIT(9) EQU 15 CON) 
*#IT(1@) FQU 16 (12N) 
*#TTC11) FOU 17 C11N) 
*#IT(12) EQU 18 C12N) 
*#ITC13) FOU 19 C1 3N) 
*#IT(14) EQU 1A (1 4N) 
*#1T(15) EQU 1B (15N) 
*#HIT(16) FQ 1C - (14N) 
*#HITCA7Z) FQU 10 (17N) 
*e#IT(18) FQU 1E (18N) 
*#ITT(19) FOU iF : (19N) 
eHIT(2@) EQU 20 (2AN) 
—eHIT(21) FQU Ai (21N) 
eHIT(22) EQ 22 C22N) 
*#TT(23) EFQU 23 | (23N) 
eHIT(24) FOU 24 (24N) 
*#IT(25) FOU 25 (25N) 
*#IT(26) FQU 26 | (26N) 
*#TT(27) EQU 27 (27N) 
eHIT(28) FQU 28 (28N) 
*#1T(29) FQ! 29 (29N) 
wHIT(3@) EQU 2A (3AN) 
*#ITT(31) Fau 2B ; | (31N) 
*#1T(32) FQU 2c | (32N) 
¥*® 

*& 

SKTP Pp 
ENN 


Figure 4-5. Generalized Coding of the #IMLAS Macro Routine 
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associated with each device assigned at system 


generation time. When the SYSGEN program 


processes the ASGP directive in its input deck, __ 


argument is not specified, the nN dummy argu- 


ment causes the source statement to be omitted 


_ from the specialized routine. That is, no PIOT 


it generates the macro call area is reserved and the symbolic tag of its 


beginning location is not completed. 

$4 #IMPIT 4 DSC), DSC,,......,DSC_ ae 
| : | At program execution time, execution of an 

When the Assembler processes the macro IOACT service request to the IOCS monitor _ 
call, it arranges the DSCs in an argument table, causes the appropriate programer- defined FIOB 
locates the #IMPIT routine on the System Macro © information to be moved to the associated IOCQ 
Library file, and replaces the dummy arguments table entry, from which the monitor subsequently 
with the actual values in the argument table. moves it into the PIOT associated with the de- 


The generalized coding of the #IMPIT routine is vice on which the I/O operation is to be per- 


formed. The PIOT is then used by the device 


driver and service routines to perform the re- 


shown in Figure 4-6. Notice the dummy argu- 


ments of the form nN at the right side of each. 


source statement. If the corresponding actual quired action, 


?HIMPIT | 

Kee KK KKK KEKE KEK KKK NK KK KKK aka kK KKK KK KKKKKKEEKEKEKKEKKEKEKKKEKE KKK 
Fe RIOT GT IIR ORR RT kkk ek kkk kek 
* 


& PIOT TABLES 
* . 
FO RR RR IIR TI III III II III III II IIIT IIe de de de det te de tke 


Fe TR I TIT III I II TO RR ER iO a tO ok kk keke tet ke tok 
A ; 


* 

MOD 16 START AT 8 WORD BOUNDARY 
wv 
#ITP(1) RESV,A 16 PIOT TABLE 1 C1N). 
#ITP(2) RESV,A 16 PINT TABLE 2 (2N) 
HITP(3) RESV,&” 16 PIOT TABLE 3 —-(3N) 
#ITP(4) RFSV,A 16 PIOT TABLE 4 (4N) 
H#ITP(S) RESV,@ 16 PIOT TABLE 5 (5N) 
#ITP(6) RESV,A 16 PIOT TABLE 6 (6N) 
#ITP(7) RESV,A 16 PIOT TABLE 7 (7N) 
#ITP(8) RESV,A 16 PIOT TABLE 8 (8N) 
H#ITP(9) RESV,@ 16 PIOT TABLE 9 “CON) 
#HITP(1H) RESV,A 16 PIOT TABLE 12 (10N) 
#ITP(11) RESV,@ 16 PTQOT TABLE 11 CL1N) 
HITP(12) RESV,A 16> PIOT TABLE 12 (12N) 
#ITP(13) RESV,@ 16 PIOT TABLE 13 “(13N) 
#ITP(14) RESV,A 16. PIOT TABLE 14 (C14N) 
wITP(15) RESV.A 16 PINT TABLE {5 7 ne 
HITP(16) PESV,S 16. PIOT TABLE 16 - (16N) 
#ITP(17) RESV,@ 16 PIOT TABLE 17 — ~ CA7N)- 
#ITP(18) RESV,®8 16 PIOT TABLE 18 | (18N) 
HITP(19) RESV,A 16 PIOT TABLE 19 —— CLON) 
#ITP(20) RESV,@ 16 PIOT TABLE 20. (20N) 
#ITP(21) RESV,A 16 PIOT TABLE 9 TO eaTNy 
#ITP(22) RESV,@ 16 PIOT TABLE 22 —(22N) 
#ITP(23) RESV,@ 16 PIOT TABLE 23 — (23N)_ 
HITP(24) RESV,A 16 PIOT TABLE 24 | —  (24N) 

Sere os ee: 5, eS ahh ee 


END 


Figure 4-6. Generalized — Coding of the #IMPIT Macro Routine 
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1,8 Driver Common Macro Routine (#IMCOM) | 


This routine is always incorporated in any 
That is, 
it is always called by SYSGEN via the macro call 


IOCS monitor that is being created. 


$A #IMCOM 


The routine contains no dummy arguments, 
hence no actual argument list appears in the 


“macro call. 


The #IMCOM routine performs all device 
independent processing required to set up for 
any I/O operation and record the status of the 


completed operation. 


The main functions of the Device Common 


Routine are: 


_ Setting up for the return of control to the 


calling routine. 


Setting up the PIOT with the information in 
words 2 through 9 of the IOCQ entry to be 


processed, 


Testing for and recording I/O status in the 
logical status field of the IOCQ. 


Disabling interrupts at the start of the IOCQ 
entry processing, and enabling interrupts 


when processing is complete. 


Starting the required I/O operation. 


1.9 Level Service Macro Routine (#IMLSR) 

A specialized version of this routine is pre- 
pared for each external interrupt level 1-8. The 
routine reserves a storage area for saving 
registers of the interrupted program, establishes | 
linkages to all driver and service routines for 


the devices assigned to each given interrupt 


4; 1-13 


level, enables invalid interrupt message logging, 


and restores the interrupted processing level. 


For each interrupt level assigned on the 
ASGP directive, the SYSGEN program generates 


a macro call in the format shown below: 


argument set 1 argument set 2 


[ing ee ga tN pe ws ey 
$A #IMLSRA Arg): Arg,, Arg,, Arg 4s Arges Arges Arg, ATg9; see 
argument set 8 
i rae 
Vi ees ATE5 4) ATB 555 ATE5¢ 


where: 


Arg, is the interrupt level to be serviced by 


a given level service routine 


Arg, is a logging flag if the System Log 
device was assigned a LUN ID via the 
ASGL directive, or 00 if no device was 


assigned. 


The remainder of the arguments in the 
$A#IMLSR statement call list form three argu- 
ment sets, where the left argument in each set 
is the first two characters of the device identi- 
fier, the second argument is the third character 
of the device identifier (i.e., the decimal 
integer portion of the identifier, denoting the 
specific device of a given type), and the third 
and last argument in the set is the DSC para- 
meter specified for each device on the ASGP 
directive. In this usage the DSC parameter 
effects specialization of the Device Driver and 
Device Service Routines for the assigned device. 
Eight argument sets may appear ina given 
$A #IMLSR macro call. 


The general coding of the #IMLSR routine 
is shown in Figure 4-7. Notice that the inter- 
rupt level (argument 1) and the logging flag 


(argument 2) are inserted in numerous places 


within the routine. As many as eight Device 
Driver Routine macro calls may be specialized 
within the #IMLSR coding set. 


macro call coding from the #IMLSR routine is 


The generalized 


as follows: 


$ FIMN( 3) (4),(4),€2)-€1),05) (3N) 
d ~#IMDCaQ) (6)-07),02),01),€6) © © 36 (6N) 

§ #IMD (CY) (9),¢0180),(02),(€1),011) (9N) 

b #IMD(12) (12),¢613),0€2),01)5614) (12N) 
% #IMNC15) 8 (€15)-016)-,02)-01)-(17) C15N). 
% HIMDC1IR) (18),019),0€2)-C€1),(20) C18N) 
3 #IMDC21) (€21)3,€22),(2)-,(1)-023). (21N) 
$ #IMN(24) (24),(25),(2)-(1),(26) (24N) 


Each Device Driver Routine name (#IMD(n)) 
is specialized by inserting the two character 
alphabetic portion of the device identifier in the 
place of the dummy argument that appears at 
the right end of the name. The two characters 
of the identifier also becomes the first actual 
argument in the call. The second actual 
argument contains the decimal integer portion 
of the device identifier. The third actual argu- 
ment contains the logging flag, and the fourth 
actual argument contains the interrupt level. 
The fifth actual argument contains the DSC 


parameter from the ASGP directive. 


Notice also that a given Driver Routine 
macro call is not generated if an argument set 
in the $4 #IMLSR macro call is not specified, as 
controlled by the dummy arguments of the form 
(nN) at the right end of the generalized state- 


ment coding. 


Note also that if no logging device has been 
assigned (i.e., if the second argument in the 
$ A#IMLSR call is 00), the coding of the Invalid 
Interrupt Logging Routine is to be omitted from 
the specialized #IMLSR coding, as specified by 
the dummy argument of the form (n, E, 00) at the 
end of each statement of the generalized routine 


coding. 


1,10 Device Driver and Service Macro Routines 


For each device attached to a given PTS- 100, 
a Device Driver Routine and a Device Service 
Routine must appear inthe IOCS monitor to be 
used on the system. For all standard devices 
supplied with the PTS-100, generalized driver 
and service macro routines appear onthe System 
Macro Library file. For nonstandard de- 
vices, the user must assume the responsibility 


of designing, implementing, and incorporating 


the required driver and service routines in the 


IOCS monitor. 


Generalized device driver and device ser- 
vice routines are called via macro calls within 
the level Service Routine (#IMLSR) for the 


interrupt level to which the associated device 


is assigned, as described in subsection l. 9. 

The generalized device driver and service macro 
routines are specialized with the three- 
character device identifier (i, es » arguments 1 
and 2 in the macro call specialized within the 
#IMLSR macro routine). That is, the device 
identifier replaces dummy arguments 1 and 2 
throughout the driver and service macro rou- 
tines for the assigned device. Generalized 
macro routine coding for the Modem Send Driver 
and Modem Send Service routines is illustrated 
in Figure 488, Other driver and service rou- 
tines for standard PTS-100 devices are coded in 
the same manner, That is, the device identifier 
is inserted throughout the generalized routines 


to specialize addresses, tags, etc. 


1,11 Monitor Service Call (MSC) Macro © 
Routine (#IMMSC) © | 


This macro routine is incorporated in each 
IOCS monitor that is being created. It performs 
the necessary processing for entering interrupt 
level 9 and for calling the appropriate MSC 
routine (e.g., OPEN, CLOSE, INITialization, | 
IOACT, etc.). The SYSGEN program generates 


the macro call statement: 


| $ A #IMMSC 
to cause the MSC routine to be incorporated in 
the IOCS monitor. Since there are no argu- | 
ments in the call statement, the entire #IMMSC 
routine is written into the IOCS monitor file by 


the macro processor of the Assembler. 
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?#IMLSR 


Hea HHH KEKE ahead Kew KaKKKHKKeKKRM KKK Keke KKK e 


kKkkkkakkkkekkkkekkhehkh kr kkk kh kee kaha kK KKK HK KEKE KKK KEE KKH KK KKK KKK Kea KS 
* 


* LEVEL (1) SERVITICF ROHTINE 
* 
* ENTFREI) FROM NEW PC OF INTERRUPT PACKET 


kkk k kak kek kkk keke keke Khe kkk kkk Kahr k kh hake KKK KKK KK keh KKK KKK Keke kek 


Wekewkehkkkeka kek kk kkk kaka keke haere hhh ka Keke KKK Kee K Kerker Keke kk kkk ke 
* 


#IXT1i(1) RESV,A 6 
weemmeme SAVE DEGISTERS 
H#IXSR(1) SX1 #1XT1(1) SAVE xX] 

SX? HTXT1(1)+2 SAVE x2 

STW e#TXTI(1)+4 SAVE AC 

SKIP p 
$ #IMD(3) (3),04),(2),(1),(5) (3N) 
g #IMID( 46) (A), (7)7(2),01),0(8) (6N) 
$ #IM0(9) (99,018), 02)-01)-011) (9N) 
$ HIMD(12) (12),(€13),02)-(1),(14) (12N) 
§ HIMDCI5S) C15), C160, 026 0399- C17) C15N) 
$ H#IMDC(1R) (C1R),019),02)-011, 020) (18N) 
$ HIMD(P1)2 (€21),022),02),061)-(23) (21N) 
§ #IMD(24) (24),(095),02)+(011,0(76) (24N) 


wee ee ER ee keke (2,6, 14) 
RI III I IOI ok totic §(2,E,00) 


* (2,E,A0) 
tome ae mm INVALTI INTERRUPT LOGGING (2?,E,aM) 
* (2,b,0A) 


WO EEK EE KEE Kae kek kkk keke (2,6, UU) 
Re EERE eek kkk kk eee (2,6, 04) 


Lx2 #IX(1)PA (2,6,a%) 
JMP #I7LOG | (2,E,U%) 
HF x A(1) a6 (2,E,00) 
#1TXC1)P% ADC +2 (2,6,AA) 
Sk IP 2 (2,E, AW) 


CESS ECCS PSCC CSP Pe CCS Se SPCC Pee See Ce ee Pee ee Cee ee eee ee eee 
FI I III III III II III I III III II I III IIIT toto tot 
* 

* LEVEL (1) RESTORE ROUTINE 

* 

SIS P CSCS CC CS eS CCS CPSC ee eT Cee eC CPSP SECS Pee eee 


Kee KKK KKK KKK KK KKK KK KKK KKK KK KhKhEK KKK KKK Kee 
* 


kewmeeRESTORE REFGTSTERS 


#IX(1)99 [x1 #IXT1(1) RESTORE X14 
1x2 H#IXTI C1) +2 RFSTORE xa 
L DW #IXT1IC1)+4 RESTORE AC 
INR 
SKIP p 
FIND 


Figure 4-7, Generalized Coding of the #IMLSR 
Macro Routine 
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PHIMDMS 
wkkekkkwkkkkkkkaekkk hk kaha keke keke hae we KKK KKKKK KH KK KEK 
Wk eK aR KEE EK Ka KKK KEKE KEKE KES 


r MODEM SEND DRIVER 
* Vidhan : . 

* 

hi yale CALLING SEQUENCE 

* Lax RETURN 

t JMP,N,X1 4 


PCB ADR IN Xt 
~*RETURN NSI | 
ee ee ede de de te te ee te ge Hee ie tek te ee tie ede ie ede i de de tee de dete dk ie ede de ttt de de te keke de de tek kk ek 
Fee ee ee i eT IO II RIO RI RI I IO kt tO tok kok 


* 


kramer e CONTINUE CHAINING 


#IW(2)3A0 |DW,N #IW(2)TO 

- XOR © #IW(2)C4 
ANY #IW(2)C6 
ADD #IW(2)C7 
STW,N #IW(2)T@ 
JMP #IW(2)49 > 
Figure 4-8. 


i om we ne oe DRIVER CONTROLS 
JMPe #IW(1)€2) 
HE x — BnAaA CHAINING FLAG 
AIlw(2)TA ADC #17T(1)(€2) PCB ADNRESS 
*& 
Satta SFT UP RETURN 
#1N(€1)¢2) SXx2 HIW(P)TI SET tIP RETURN JLIMP 
* 
komme TEST FOR LEGAL OPERATION 
LX¥2,x1 8 IOCQ-OHUT ADR TO X2 
LOW,x2 4 FETCH. COMMAND. WORD 
AND HIW(2)C1 sX'atna! 
CNE HIW(2)C4 
RCR —#IW(AIAL TLLFGAL 
LOW,X2 4 FETCH COMMAND WORD 
AND #IW(2)C2 =x 'Aeguat 
CAL #IW(2)C3 zx! Agna! 
RCB #IW(72)20 LEGAL 
JMP #IW(2) 01 ILLEGAL 
m | 
kamwenme SFT UP INTERRUPT MASK 
#Iw(2)20 LDI AC,X'6a! FETCH INT MASK 
STH, X2 3) STORE IN JIOCQ 
* 
K oo we oe CALI NORIVER COMMON 
. SX 4 #IW(2)P1 STORF PCB 
LAX2 #IW(2)4G : 
JMP #INDCOM GO TO DRIVER COMMON 
HIW(2)P1 HEY A PCB ADNRESS 
* 
te IS THE CHAIN FLAG SET ? 
#2IW(2)40A LDW,X1 A FETCH COMMAND WORD FROM PIOT 
AND #IW(2)C4 =xX'iaaa' 
RCR #IW(2)30 YES 
* 
ee a ce oe STOP CHAINING . 
| DW,N #IW(2)TO FETCH PCB STATUS 
AND #IW(2)C5 =X 'FRFF t 
STW,N #IW(2)T@ REPLACE PCB STATUS WORD 
* 
tom me EXIT | 
#IW(2)49 JMP,N #IW(2)T1L RETURN TO CALLER 
* 
1 mo ae om oe oe ILLFGAL OPERATION 7 | 
#IW(2)01 LOT ACsX'@318',L SET UP STATUS CODE 
STW,X2 2 i STORE IN IQCQ 
JMP H#IW(2)49 GO TO EXIT 


FETCH PCB STATUS WORN 
=X'4a90' INVERT A/B FLAG 


—sX'FRFF! 


=X'9490' SET SKIP FLAG 
REPLACE PCB STATUS WORD 
GO TO EXIT 


Generalized Coding of the Modem Send Device Driver 


and Device Service Routine (fIMDMS) 


(Sheet 1 of 3) 
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* 

kane CONSTANTS 
#Iw(2)Ci KEX ALA 
#IW(2)C? HEY AE VA 
RIw(2)C3 HEY AIAN 
#IW(2)C4 HEX 1aaa 
#IwW(2)C5 HEX FRFF 
bIlw(2)C6 HEX FRFF 
aIw(2)C7 HEY A AIAA 
* 

keen VARTARBLFS 
HIW(2)T1 HEY G RETURN ADDRESS 
* 


SKIP zs 
week kee eae eek kaka hake hhh kde keh kkk kh kaka ard keh kee aKa dea Khk kkk kaka & 
Khe kkk kkk keke kkk dk kkk keh kha kkk keh hh keke keke kkk Kk Kehr Kak hd kkk kkk kek Kk kk 


+ MODEM SEND SFRVICE ROUTINE 
ke meee ENTERED FROM LEVEL SERVICE ROUTINE 
wee KEKE KK KEKE KAKA KE KK KKH KAKEAKEKHEEMEKKEKKKEKEK KKK Keke Ke Keke KEK KKK KKK KEES 


wkekwekkekke kkk ka keke hh kk kkk aKa Keke Kh keke kkk Kh kkk kha KKK Keke KKK KKK Keke eK 


ee RFAND AND RESET STATUS 


#Iw(1)(?) LX H#ITWw( PITA PUT PCR ADR IN Xf 
L Ow, xX! 2 FETCH NEV ADR 
AND HIW(?)CR =X'AFFF! 
RTO #IW(2)T3 REAM + RESET ICB 
L¥O,Xx4 B TOCA ADR Ta x? 
* 
kee TEST FOR RYTE COUNT = u 
PI AC,X'4! 
AND HIW(?)TS3 RYTF COUNT = A? 
KCK #IW(?)50 YES 
* 
Se aie sates TFST FOR DEVICE NOT REARY 
LO] AC,xX'20a! 
AND #]W(?)T3 NEVICE NOT REFANY? 
KOK AIWC2)7H YES 
* 
tm ee 560 TO NEXT DSR 
JMP #IW(?)99 B60 TA NEXT DSR 
* 
a oe BYTF COUNT = @ 
#Iw(2)54 LDW #IW(2)CC =xX'aAzaor 
STw,X? 2 MPNATE INCQ STATUS 
* 
keeenmTS CURRENT ORDER CHAINED ? 7 
LOW,X? 4 FETCH CURRENT ORDER 
AND #I]W(2)C4 =Xt yma 
HCB #IW(?P)52 CURRENT ORDER IS CHAINED 
* ‘ 
w 
* 
koe UPDATE TOCQ-QUT 
LOW, X? A | NEW TOCQ ADR 
JMP #IW(2)57 
* 
tm ame UPDATE STATUS OF NEW ENTRY 
#IwW(2)5? LX2,xX2 A NEW TOCQ TO X2_ 
SX2 HIW(2)T4 SAVF NEw TOCQ 
LOW | #IW(2)CD =X! aognn! 


STWw,X2 D) UPNATE NEW ITOCQ STATUS 


Figure 4-8, Generalized Coding of the ModemSend Device Driver 
and Device Service Routine (#IMDMS) 
(Sheet 2 of 3) | 
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enn IS NEW ORDER CHAINED 


#IW(2)54 LOwW,X? 4 FETCH NEW ORDER 
AND #IW(2)C4 =X' {aga 
BCB #IW(2)53 YES 
JMP #1W(2)56 NO 
* 
kone me LOOK=AHEAND TO NEXT IOCQ ENTRY 
#IW(2)53 Lx2,X? @ 
LNB, X? 2 FETCH LOGICAL STATUS 
CNE #IW(2)C8 =X'AAAL' 
BCB #1W(2)56 NOT I/N PENDING 
* 
komo oe GN TO MODEM SEND DRIVER 
SX2,X1 8 LOOK=AHEAD ADR TO PCR 
LAX? #IW(2)56 | 
JMP,N,X1 4. GO TO DRIVER 
km RFSTORE NEW JTOCQ-0UT 
#TW(2)56 LDW #IW(2)T4 | 
| LX4 #IW(2)TQ PUT PCB ADR IN Xi | 
#IW(2)57 STW,X1 8 RESTORE IOCQ-OUT IN PCR 
¥ : 2 
tom ee EXIT TO LEVEL RESTORE ROUTINE 
#Iw(2)59 JMP #1X499 EXIT TNA LSRR 
* ; 
Sosa as a say -DEVICE NOT READY 
#IwW(2)70% LbDwW #IW(2)C9 =X'A341! 
HIW(2)72 STW,X2 2 UPDATE IOCQ STATUS WORD 
JMP #TW(2)59 GO TO EXIT 
* 
* 
tome CONSTANTS 
#IW(2)C8 HEX AAAL 
#IW(2)C9 HEX A344 DEVICE NOT REANY 
#Iw(2)CR HEX OFFF | , 
#IwW(2)CC HEX A3Ia2 BYTE COUNT = g 
#Iw(2)CD HEX AZADA | 
* 
* 
keno VARIARLES | 
#IW(2)T3 HEX 4 ICB STATUS 
#IW(2)T4 HEX A NEW TOGQ=\OUT 
* 
te GO TO NEXT DSR 
#IW(2)99 EQ rs 
* ot 
SKIP = =P 
END 


Figure 4-8, Generalized Coding of the Modem Send Device Driver 
and Device Service Routine (#IMDMS) 
(Sheet 3 of 3) 
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1,12 EXIT Macro Routine (#IMEXT) device identifier, the identifier becomes the 
argument in the $A #IMEXT call. The second 


The EXIT macro routine is incorporated in form of the call statement is generated if the 
each IOCS monitor that is created. It effects a third entry in the ASGL directive was 000 (i.e., 
system exit. The EXIT macro routine is if no logging device was assigned). 


specialized according to the form of macro call 
that SYSGEN generates: The generalized coding of the #IMEXT 


macro routine contains statements to effect 


$A #IMEXT A Arg message logging if a System Logging Device was 
oF assigned. These statements contain dummy | 
$\#IMEXTA,, arguments of the form (1N). Thus, if the logging 
device identifier is transmitted inthe $A #IMEXT 
The first form of the call statement is used if a macro call, the logging statements are inserted 
System Logging Device was assigned via the in the specialized routine; otherwise, they are 
ASGL directive input to SYSGEN. That is, if omitted. The generalized #IMEXT macro rou- 
the third entry of the ASGL directive was a valid tine coding is shown in Figure 4-9. 
PH IMEXT 


WWE KKK EK KK KKK KKK Ke Khe Khe Khe K Kedah kkk Keke Kk Keer Khe 
Kee Keke Kea KKK KKH KKK KEK KKK KKK Kk Kk KKK 


* ~FXTT ROUTINE 
¥ 

i sa aa ak CALLING SEQUENCF 

* MOC 

* DFC (A 


WERKE KREKEKRKEREE KE KKK KK KKK KKK KKK KKK KKK HK KK Kha KKK KKK 
khkiebwkke kane kkk eke kkk keke kkk kak kk ae Keka KK kkk keh kkk hk Kha kkk hk keke 


* 
* 
* 
te me ClEAR LOC A AND OLD PC 
@IVEXKT LIYI AC,@A 
STW HITUATI 
STw #ITTPG CLFAR OLD=PC OF INT LEVEL 9 
* C1N) 
teeeennnl AG END OF JOR CIN) 
1 AX? HIAAP | C1N) 
JMP WIZLOG LNG END OF JOB (1N) 
DFC AAA C1iN) 
AIWUPI FQu * 
* (1N) 
temo weonn GN TO A 
INR . STALL AT ZERO 
. | 
SKIP Pp 
END 


Figure 4-9. Generalized Coding of the EXIT Macro Routine 
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1,13 CLOSE Macro Routine (#IMCLL) 


The CLOSE macro routine is specialized 
for each IOCS monitor that is created. This 
routine performs the processing required to 
close a specified device. It is specialized 
according to the form of macro call that SYSGEN 


generates: 


$A #IMCLLA Arg 
or 


$A #IMCLLA, 


The first form of the call statement is used if a 
System Logging Device was assigned via the 
ASGL directive input to SYSGEN. That is, if 
the third entry of the ASGL directive was a 
valid device identifier, the identifier becomes 
the argument in the $A #IMCLL call. The 
second form of the call statement is generated 
if the third entry in the ASGL directive was 000 


(i.e., if no logging device was assigned). 


As in the #IMEXT macro routine, state- 
ments appear in the generalized #IMCLL macro 
routine to effect message logging when a Sys- 
tem Logging Device has been assigned. When 
the $4 #IMCLL call transmits a logging device 
identifier as its argument, the logging state- 
ments (containing dummy arguments of the type 
(1N)), are inserted in the specialized routine. 

If a comma is transmitted in the $4 #IMCLL call 
statement, the logging statements are omitted 


by the Assembler's macro processor phase. 


1,14 INITialization Macro Routine (#IMINT) 


The INITialization routine performs the 
processing required to initialize all devices in 
the equipment configuration. This routine is 
always incorporated in the IOCS monitor being 


created. SYSGEN generates the statement: 


$A #IMINT 


to cause the routine to be incorporated in the 
monitor. No arguments are supplied in the call, 
and no dummy arguments appear in the genera- 
lized coding. That is, the entire routine is 


incorporated in the IOCS monitor. 


1,15 OPEN Macro Routine (#IMOPL) 


The OPEN routine performs the processing 
required to OPEN a specified device. It is 
specialized for each IOCS monitor that is 
created according to the form of macro call that 
SYSGEN generates: 


$,; #IMOPLA Arg 


or $A #IMOPLA, 


The first form of the call statement is used if a 
System Logging Device was assigned via the 
“ASGL directive input to SYSGEN. . That is, if 
the third entry of the ASGL directive was a 
valid device identifier, the identifier becomes 
the argument in the $A #IMOPL call. The 
second form ofthe call statement is generated 
if the third entry in the ASGL directive was 000 


(i.e., if no logging device was assigned). 


The generalized coding of the #IMOPL 
macro routine contains statements to effect 
message logging if a System Logging Device has 
been assigned. If the logging device identifier 
is transmitted in the $4 #IMOPL call, the 
logging statements (containing the dummy argu- 
ments (1N)), are inserted in the specialized 


routine; otherwise, they are omitted. 


1,16 IOACTion Macro Routine (#IMACT) 


The IOACTion macro routine is specialized 
for each IOCS monitor that is created. This 
routine performs the processing required to set 
up for and start input/output operations. The 


SYSGEN program generates the macro call: 
$A #IMACTA Arg 


or $A #IMACTA, 
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to effect specialization of the #IMACT routine. 
The first form of the macro call is used if a 
System Logging Device was assigned via the 
ASGL directive input to SYSGEN, That is, if 
the third entry of the ASGL directive was a 

valid device identifier, the identifier becomes 
the argument inthe $4 #IMACT macro call. The 
second form of the $4 #IMACT call is used if 

the third entry in the ASGL directive was 000 


(i.e., if no logging device was assigned). 


The generalized coding of the #IMACT 
macro routine contains statements to effect 
message logging if a System Logging Device 
was assigned. If the logging device identifier 
is transmitted inthe $A #IMACT call, the log- 
ging statements (containing the dummy argu- 
ments (1N)) are inserted in the specialized 


routine; otherwise, they are omitted. 


1,17 Compute PCB Address Macro Routine 
(#IMPCB) | 


This macro routine is always incorporated 
in the IOCS monitor being created. As its name 
implies, its function is to compute the addresses 
of the Physcial Control Blocks (PCBs) for 
assigned devices. The SYSGEN program gener- 


ates the macro call statement: 
$A #IMPCB 


to cause the entire routine to be inserted in the 


IOCS monitor being assembled. 


1,18 Error Logging Macro Routine (#IMLOG) 


This routine produces the logging messages 
on the System Logging Device when it has been 
assigned. The routine contains the LUN Con- 
version Table, the Message Locate Table, and 
the Canned Message Table. When a System 
Logging Device ‘is assigned on the ASGL direc- 


tive input to SYSGEN, the macro call: 


$a #IMLOG 


42 y291 


is generated. At assembly time, the entire 
Error Logging Routine is inserted in the IOCS 


monitor being created. 


The Error Logging Routine is called by the 
MSC service routines when the error logging 
statements have been incorporated in them. That 
is, when a logging device identifier is transmitted 
as the argument in the MSC service routine macro 
calls generated by SYSGEN, the logging state - 
ments are included in the specialized versions of 


the EXIT, OPEN, CLOSE, etc., service routines. 
1.19 Clock Service Macro Routine (#IMCLK) 


The Clock Service Routine performs the pro- 
cessing required when the interval timer interrupt 
is selected by the user. 
level 0. It is specialized according to the form 


of the CALL directive to SYSGEN: 


The interrupt occurs at 


CALL, $A #IMCLK, Arg,,Arg, 


or CALL, $\#IMCLK, Arg, 

The first form generates the modified version 
of the clock. This version of the clock allows 
linkage to user specified subroutines when a clock 
expires. Arg, must be the letters MT (modified 
timer). Arg? specifies the number of clocks to 


be generated. 


The second form is used to generate the 
standard version of the clock, which decrements 
the clock to zero without subroutine linkage. Arg, 


specifies the number of clocks to be generated. 


When the CALL directive is processed by 
SYSGEN, the CALL statement 


$A #IMCLK 


is written onto the Assembler-formatted output 


file. When the Assembler's macro processor 


reads the macro call, it writes the Clock Ser- 


vice Routine onto its output work file. 


1,20 Parity Error Macro Routine (fIMPAR) | When the SYSGEN program interprets the | 
| 7 CALL directive it generates one of the following 
The parity error interrupt level 10 is macro call statements: 
optional, The user specifies the inclusion or 
ae Sa nde $ A#IMPAR AArg 
exclusion of the interrupt level via a CALL di- | a | 


pective in the format: | ae | $h HIMPARA , 
CALL, $, #IMPAR a Arg : . , | 
, | . he | The Parity Error Routine is specialized 
or | CALL,$A#IMPAR)A,. | according to the form of the macro call that is 
a | | _ 2. = | issued. The generalized coding of the Parity 
as the input to the SYSGEN program. Error Routine is shown below: | 


2#IMPAR 
We ee ee ee te ie ie i de de vi i dee de de a te eee ee ete de de te ie idee ie ide dei te de vee de kote de de ie die de de dedi te de eke doko 


Hee de te te te de tek te te I EE REE KE KEKE EKEEKKKKKKKKKKKKKKKK KKK ht 
* : : | 


" | PARITY ERROR ROUTINE 
. | , 

* CALLED FROM INTERPUPR LEVEL 1@ 
* 


ESE E CSOSA CCS CLCLSCCCCSSSLSCLT SCSI CCL COLT LCT Tt 
Keke KR KEKE Kea EKEKHEKEKE KKK KEKE eek Kk kaka dea ke 


RAIVPAR LDw #IVPAA 
AND H#IVCAL 
STw #IVPAD 
JMP —  #TVP99 : | LY) 
| AX2 H#IVP9Y (1N) 
JMP #1 7LOG | C1N) 
#IVPOA DEC BAS 
#ITVP99 INR EXIT 
RIVCHL HEX A190 
SKIP. pP 
FND 
If the first form of the call statement is form of the call statement is issued by the 
issued, the first JMP statement is omitted from SYSGEN program, the first JMP statement is 
the specialized #IMPAR routine because of the included in the specialized Parity Error Routine, 
(1Y) dummy argument, and the LAX2 and sécond and the LAX2 and JMP statements are omitted. 


JMP statements are included. If the second 
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Section 2. USER MACRO LIBRARY FILE 


The User Macro Library is a collection of generalized, source-coded routines that may be called 


within applications source programs to effect the following: 


® Creation of FIOBs and IOCQ Table entries 
® Monitor service calls to perform the following: 


READ operations on an input device 
WRITE operations on an output device 
REWIND operations on I/O devices 

OPEN devices 

CLOSE devices 

INITialize all devices on the system 

Cause a System EXIT 

Control or interrogate the Watchdog Timer 


Sense device status 


Test and reset lists of devices attached to the Channel Interface Controller 


e Inclusion of Translate Tables for use in translating 2260 keyboard code, ASCII 
keyboard code, and the IPARS keyboard code to the internal ASCII code 


e Conversion of Baudot to ASCII code and ASCII to Baudot Code used with the 
ASR 32 teletype device. 


The routines are called via macro call statements within the user's program. The format of the 


call statement is: 
$ macroname argument list 


where the $ appears in column 1 of the coding form, followed by a blank character. The name of the 
macro routine then appears, followed by a blank character. The argument list, if required, then 
appears, where two or more arguments are separated by commas. If a required argument is to be 


omitted from the list, its omission is indicated by a comma in the argument's position in the list. 


When a program contains macro call statements, the User Macro Library file must be input to the 
Assembler for use by the macro processor in specializing the called macro routines, as described in 
Part 2 of this Handbook. | 


The remainder of this section presents detailed descriptions of the User Macro Library routines 


and the manner in which they are called in source programs. 


2.1 IOFIOB Macro Routine 

The 1[OF1OB user macro routine effects specialization of the source statements that construct a 
File Input/Output Block (FIOB) describing the parameters of each IOACTion service to be performed 
by IOCS. The generalized coding of the IOFIOB macro routine is shown below: 


7IOFIOB 

(1) HEX O SPARE/FRROR CONE 

(2)4 HEX (3) MONE, FUNCTION, LOG UNIT NO 

(2)? ANC (4) RUFFER ADDRESS 4 

(2)3 DEC (5) BYTE COUNT 

(2)4 ADC (6) TRANSLATE TABLE BASE (QY) 

(2)4 HE X (6) DISK TRACKeCYLINDER ADDRESS (ON) 

(2)5 ADC (7) SEARCH TABLE BASE (9Y) 

(2)5 HE X (7) DISK SECTOR ADDRESS (ON) 
RESV,A 4 SPARE 

(2)8 HEX  aaa(s) SPARF/LUN FXTENSION NUMBER 

END 


The macro routine contains nine dummy arguments, and therefore nine arguments must be trans- 


mitted in the IOFIOB call statement. These arguments are defined below. 


Argument |: The starting location (e. g., symbolic tag) of the specific FIOB to be 


created must appear in the first position of the call statement list. * 


Argument 2: The first portion of a symbolic tag for the constant defining statements 
in the FIOB must appear as the second argument in the macro call 


statement. * 


Argument 3: The data transfer mode, device function code, and logical unit number 
(LUN) of the device on which the LOACTion is to be performed must be 


specified as argument 3. 


Argument 4: This argument specifies the starting address of the buffer to or from 


which I/O data is to be transferred. 


Argument 5: This argument specifies the number of bytes of data to be transferred to 


or from the I/O buffer. 


Argument 6: This argument specifies the starting location of the Translate Table if 
the I/O action is to be performed on a device other than a disc or the 
address of the disc track and cylinder if a disc device is to be used in 


the I/O operation. 


RO NC eR RTT REE A PN CO ED Po At OE AMET ip 


*Arguments 1 and 2 supply labels for statements in the FIOB. The first argument supplies a 
complete label and may be six characters or less; the first character must be alphabetic. Argument 
2 specifies five or less characters of a label; the first character must be alphabetic. 


Argument 7: 


Argument 8: 


Argument 9: 


This argument specifies the address of the starting location of the Search 
table if the I/O operation is to be performed on a device other than a disc, 
or the address of the disc sector if a disc device is to be used in the 


operation. 


The LUN extension number of a specific device on a device controller 


to which multiple devices may be attached. 


This argument must be a | if the I/O operation is to be performed on a 
disc device, or a comma (,) if any other device is to be used for the 

I/O operation. If a1 is specified as the ninth actual argument in the 
$IOFIOB call statement, the Translate and Search Table address constant 
statements are omitted from the specialized routine and the disc track- 
cylinder and sector hexadecimal constant statements are included. lfa 
comma is transmitted in position 9 of the call statement argument list, 
the ADC statements specifying the Translate and Search Table addresses 
are included in the routine and the disc address statements are omitted 


from the specialized routine at assembly time. 


The call statement: 


$ IOFIOB FIOBI,JVC,FFFF, BUFF1, 320, 0208, 0040, 0, 1 


causes the following routine to be specialized at assembly time. 


FIOBI HEX 0 SPARE/ERROR CODE 
IVCl HEX FFFF =  MODE,FUNCTION, LOG UNIT NO 
IVC? ADC BUFF1 BUFFER ADDRESS 
IVC3 DEC 320 BYTE COUNT 
TVc4 HEX 0208 DISK TRACK-CYLINDER ADDRESS 
IVCS5 HEX 0040 DISK SECTOR ADDRESS 
RESV,0 4 SPARE 
IVC8 HEX 0000 SPARE/LUN EXTENSION NUMBER 


The call statement 


causes the following routine to be specialized. 


FIOBZ HEX 0) SPARE/ERROR CODE 


$ IOFIOB FIOB2,JVC,2401, BUFF1,80, TRANS,SRCH,4,, 


JVCl HEX 2401 MODE,FUNCTION, LOG UNIT NO 
JV C2 ADC BUFF 1 BUFFER ADDRESS 
JVC3 DEC 80. BYTE COUNT 
JV C4 ADC TRANS TRANSLATE TABLE BASE | 
JVC5 ADC SRCH SEARCH TABLE BASE 

RESV,O 4 | SPARE 


JVC8 HEX 0004 SPARE/LUN EXTENSLON NUMBER 


2.2 IOIOCQ Macro Routine 


The IOIOCQ user macro routine effects specialization of source statements required to set up 


entries in the IOCQ table. The generalized coding of the routine is shown in Figure 4-10. 


The IOIOCQ macro may be called to generate a single IOCQ entry or a maximum of eight IOCQ 
entries. In all cases, the IOCQ name base must appear as the first argument in the list of the 
~$I1OLOCQ call statement. Following the name base may be from one to eight modifiers to the name 
base.* These modifiers uniquely identify individual entries in the IOCQ table being generated. As in 
all macro call statement lists, the individual arguments in the list are separated by commas, and 


omitted arguments are indicated by commas. 


To effect the creation of a single IOCQ table entry, the user specifies the name base, anda 


single name base modifier followed by eight commas. For example, the call statement 
$ IOIOCQ 1LOCQ , Aves o003 


specifies that only one entry is to be created in the IOCQ table. The name base is to be IOCQ, and the 
modifier A is to be used to specialize the entry. The following coding will be produced as a result of 


the single entry call. 


IOCQA ADC IOCQA LINK 

HEX 0 LOGICAL/ PHYSICAL STATUS 
HEX 0 MODE, FUNCTION, LOG UNIT NO 
HEX 0 BUFFER ADDRESS 
HEX 0 ) BYTE COUNT 
HEX 0 | TRANSLATE TABLE/ DISK ADDRESS 
HEX 0 SEARCH TABLE/DISK ADDRESS | 
RESV,0 6 SPARE | 


If several IOCQ entries are to be created, the IOL[OCQ macro call statement list contains the name 
base as the first argument, followed by a comma and the appropriate number of name base modifiers. 


For example, the call statement 
$IOIOCQ ~I0CQ,A,B,C,D,,,,, 
specifies that four IOCQ entries are to be created. The name base is to be IOCQ, and the four entries 


are to be specialized with the arguments A, B, C, and D. The following coding will be produced by 


the call statement: 


*Since the name base and the modifiers complete the label fields of the LOCQ table, the combined 
number of characters must not exceed six characters; the first character must be alphabetic. 


IOCQA 


IOCQB 


IOCQC 


IOCQD 


ADC 
HEX 
HEX 
HEX 
HEX 
HEX 
HEX 
RESV, 0 
ADC 


ADC 


ADC 


2.3 READ Macro Routine 


IOCQD 


IOCQA 


LINK 

LOGICAL/ PHYSICAL STATUS 
MODE, FUNCTION, LOG UNIT NO 
BUFFER ADDRESS 

BYTE COUNT | 
TRANSLATE TABLE/ DISK ADDRESS 
SEARCH TABLE/ DISK 

SPARE 

LINK 


LINK 


LINK 


The READ user macro routine effects specialization of the source statements required to perform 


a read operation on an input device. 


below. 


? READ 


END 


MSC 
HEX 
ADC 
ADC 


7 
(1) 
(2) 


The generalized coding of the READ macro routine is shown 


MONITOR SERVICE CALL 
I/O ACTION CODE 
RETURN ADDRESS 

FIOB ADDRESS 


Since there are two dummy arguments in the routine, the call statement to the routine must transmit 


two actual arguments, as follows: 


Argument |: 


Argument 2: 


This argument specifies the user program address to which IOCS is to 


return control on completion of the read operation. 


This argument specifies the address of the FIOB* associated with the 


device on which the read operation is to be performed. 


*Prior to the appearance of a READ call statement, an FIOB with a READ function code must 


have been established in the calling program. 


: 2-5 


2 L6106Q—-—----- 


LINK (3Y) 


(1) (2) ADC (1) (2) 
~(1)02) ANC (1)(3) LINK (3N) 
HE Xx a LOGICAL/PHYSICAL STATUS (2N) 
HEX ") MODE, FUNCTION, LOG UNIT NO (2N) 
HEX a _ BUFFER ADDRESS (2N) 
AHEM = pe mn RT E-COUNT CON) 
HE X ) TRANSLATE TABLE/DISK ADORESS (2N) 
HE X a SEARCH TABLE/DISK ADNRESS (2N) 
RESV,@ 6 SPARE (2N) 
(1) (3) ADC (19(2) LINK (4Y)(3N) 
(1) (3) ADC (1)(4) LINK (4N) 
ee EX oe --LOGICALAPHYSICAL STATUS (3N) 
HE X ) MODE, FUNCTION, LOG UNIT NO (3N) 
HE Xx a BUFFER ADDRESS (3N) 
HE X a BYTE COUNT (3N) 
HE X a TRANSLATE TARLE/DISK ADDRESS (3N) 
HE X A SEARCH TABLF/DISK ANDRESS (3N) 
RESV,@-.. 6... SPARE (3N) 
(1) (4) ADC (1) (2) LINK (5Y)C4N)(3N) 
(1) (4) ADC (1) (5) LINK (5N) 
HE X A LOGICAL/PHYSICAL STATUS (4N) 
HE X a MODE, FUNCTION, LOG UNIT NO (4N) 
HE X a BUFFER ADDRESS (4N) 
HE X 7) BYTE COUNT (4N) 
HE X ) TRANSLATF TABLFE/DISK ANDRESS (4N) 
HE X ) SEARCH TARLF/DISK ADDRESS (4N) 
RESV,@ 6 SPARF (4N). 
(1) (5) ADC (1) (2?) LINK CSV). CSN) CANYCSN) 
(1) (5) ADC (1) (6) LINK: (6N) 
ee HEX a. LOGICAL/PHYSICAL STATUS (5N) 
HE X a MODE, FUNCTION, LOG UNIT NO (5N) 
HE X a BUFFER ADDRESS (5N) 
HE X ) BYTE COUNT C(5N) 
HE X ) TRANSLATE TARLE/DISK ADDRESS (5N) 
HE X a SEARCH TABLF/DYSK ADDRESS C54) 
os RESV ZG - & ~~ - SPARE ¢5N).. 
(1) (6) ADC (1) (2) LINK (7Y) (6N) (5N) CAN) (3N) 
(1) (6) ADC (1) (7) LINK (7N) 
HE X 1) LOGICAL/PHYSICAL STATUS (6N) 
HE X 1) MODE, FUNCTION, LOG UNTT NO (6N) 
HEX ) BUFFER ADDRESS (6N) 
HEM —---8 . BYTE -COUNT-6N) : 
HE X 7) TRANSLATE TABLE/DISK ADDRESS. (6N) 
HEX a SEARCH TABLF/DISK ADDRESS (6N) 
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Figure 4-10. 
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To illustrate the manner in which the READ routine is called, assume that the return address in 


the program is FINISH, and the address of the FIOB to be used is FIOB1. The call statement 


$ 


READ FINISH, FIOBI 


will cause the READ routine to be specialized as shown below: 


MSC 
HEX 
ADC 
ADC 


2.4 WRITE Macro Routine 


7 
FINISH 
FIOB1 


MONITOR SERVICE CALL 
I/O ACTION CODE 
RETURN ADDRESS 

FIOB ADDRESS 


The WRITE user macro routine effects specialization of the source statements required to per- 


form a write operation on an output device. 


shown below: 


? WRITE 


MSC 
HEX 
ADC 
ADC 


The generalized coding of the WRITE macro routine is 


MONITOR SERVICE CALL 
I/O ACTION CODE 
RETURN ADDRESS 

FIOB ADDRESS 


Since there are two dummy arguments in the routine, the call statement must transmit two actual 


arguments as follows: 


Argument 1: This argument specifies the user program address to which the IOCS monitor 


is to return control on completion of the write operation. 


Argument 2: This argument specifies the address of the FIOB™ associated with the device 


on which the operation is to be performed. 


To illustrate the WRITE call statement, assume that the return address in the program is 


PRINT and the address of the FIOBis PRINTR. The call statement 


$ WRITE 


PRINT, PRINTR 


will cause the WRITE routine to be specialized as shown below. 


MSC 
HEX 
ADC 
ADC 


7 
PRINT 
PRINTR 


MONITOR SERVICE CALL 
I/O ACTION CODE 
RETURN ADDRESS 

FIOB ADDRESS 


ok $. , = 
Prior to the appearance of a WRITE call statement, an FIOB with a WRITE function code must 
have been established in the calling program. 


2.5 REWIND Macro Routine 


The REWIND user macro routine effects specialization of the source statements required to per- 
form a rewind operation on anI/O device. The generalized coding of the REWIND macro routine is 


shown below. 


? REWIND 
MSC MONITOR SERVICE CALL 
HEX 7 I/O ACTION CODE 
ADC (1) RETURN ADDRESS 
ADC (2) FIOB ADDRESS 
END 


Since there are two dummy arguments in the routine, the call statement must transmit two actual 


arguments, as follows: 


Argument |: This argument specifies the user program address to which IOCS is to return 


control on completion of the rewind operation. 


Argument 2: This argument supplies the address of the FIOB* associated with the device 


on which the operation is to be performed. 


For example, assume that the program return address is RDREC and the address of the associated 
FIOB is RWFIOB. The call statement 


$ REWIND RDREC,RWFIOB 


will cause the REWIND routine to be specialized as follows: 


MSC MONITOR SERVICE CALL 
HEX 7 I/O ACTION CODE 

ADC RDREC RETURN ADDRESS 

ADC RWFIOB FIOB ADDRESS 


36: (OPEN Macro Routine 


The OPEN user macro routine effects specialization of the source statements required to opena 


specific I/O device. The generalized coding of the macro routine is shown below. 


“Prior to the appearance of a REWIND call statement, an FIOB with a REWIND function code must 
have been established in the calling program. | 


? OPEN 

MSC 
HEX 
ADC 
ADC 
HEX 
ADC 
RESV,0 2 


LUN 


(4) 
END 


MONITOR SERVICE CALL 
OPEN CODE 

RETURN ADDRESS 
PARAMETER LIST ADDRESS 


IOCQ ADDRESS 
ERROR FIELD 


The OPEN macro routine has four dummy arguments; hence, four actual arguments must be trans- 


mitted to the routine via the call statement list, as described below: 


Argument 1: This argument specifies the user 


return control when the specified 


Argument 2: 


opened. 


Argument 3: 


third actual argument. 


Argument 4: 


The label of the error code field is defined in argument 4. 


program address to which IOCS is to 


device has been opened. 


This argument supplies the logical unit number (LUN) of the device to be 


The address of the associated entry in the IOCQ table is specified as the 


This argument 


must consist of six characters or less, the first of which must be alphabetic. 


Shown below is a call statement with the proper arguments for the OPEN routine. 


$ OPEN 


START1, 1,10CQX, ERROR 


When the call statement is processed by the Assembler, the following specialized coding is pro- 


duced for the calling source program: 


MSC 
HEX 6 
ADC STARTI 
ADC #42 
HEX l 
ADC IOCQX 
ERROR1 RESV,0 2 


2.7 CLOSE Macro Routine 


The CLOSE user macro routine effects specialization of the source statements required to close a 


specific I/O device. 


? CLOSE | 
MSC 
HEX 1 
ADC (1) 
ADC *4+2 
HEX (2) 
(3) RESV,O 2 
END | 
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The generalized coding of the macro routine is shown below. 


MONITOR SERVICE CALL 
OPEN CODE 

RETURN ADDRESS 
PARAMETER LIST ADDRESS 
LUN 

IOCQ ADDRESS 

ERROR FIELD 


MONITOR SERVICE CALL 
CLOSE CODE 

RETURN ADDRESS 
PARAMETER LIST ADDRESS 
LUN a 

ERROR FIELD 


There are three dummy arguments in the CLOSE macro routine. Hence, a user macro call statement 
must contain three actual arguments to be used to specialize the coding to be incorporated in the call- 


ing program. The actual arguments are described below: 


Argument 1: The calling program return address appears as the first argument in the call 


statement list. 


Argument 2: The second argument supplies the logical unit number (LUN) of the device 


to be closed. 


Argument 3: The label of the error code field is specified as argument 3. This argument 


may consist of six characters or less, the first of which must be alphabetic. 
The call statement 
$ CLOSE FIN! , 1, ERRORZ 
will cause the fellseaay specializes sede fo be produced by the Rgsemnieee macro PeCGesson: 


MSC “MONITOR SERVICE CALL 


HEX _ Ll CLOSE CODE 
ADC FIN] RETURN ADDRESS 
ADC *+2 PARAMETER LIST ADDRESS 
HEX ] LUN 
ERROR2 RESV, 0 2 a - ERROR FIELD 


2.8 INIT Macro Routine 


The INIT user macro routine effects specialization of the source statements required to reset all 


devices onthe system. The generalized coding of the routine is shown below. 


? INIT a | 
MSC - MONITOR SERVICE CALL 
HEX Z INIT CODE | 
ADC | (1) RETURN ADDRESS 

END | 


The address constant statement contains a dummy argument instead of the user program address 
to which IOCS is to return control after the initialization operation is completed. The macro call 
statement to the INIT. routine must therefore specify the return address as its only argument. For 


example, the call statement 
$ INIT START 
will cause the following specialized routine to be inserted in the calling program at assembly time: 


MSC 7% MONITOR SERVICE CALL 


HEX 2. | _ INIT CODE | 
ADC START RETURN ADDRESS 
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2.9 EXIT Macro Routine 


The EXIT user macro routine effects the specialization of source statements required to request 
IOCS to log the end of job and cause a system exit. The generalized coding of the macro routine is 


shown below. 


? EXIT 
MSC MONITOR SERVICE CALL 
HEX 0 ALL DONE CODE 

END 


There are no dummy arguments in the macro routine; hence no actual arguments are transmitted 


to the routine in the call statement. A sample call statement is illustrated below: 
$ EXIT 
The following code will appear in the calling source program. 


MSC MONITOR SERVICE CALL 
HEX @) ALL DONE CODE 


2.10 Watchdog Timer (WDTMSC) Macro Routine 


The WDTMSC user macro routine effects specialization of source statements required to control 
or interrogate the watchdog timer. The generalized coding of the watchdog timer macro routine is 


shown below. 


? WDTMSC 
MSC MONITOR SERVICE CALL 
DEC 3 WATCHDOG TIMER CODE 
ADC (1) RETURN ADDRESS 
ADC (2) PARAMETER LIST ADDRESS 

(2) DEC 000(3) REQUEST CODE 

HEX 0 POWER STATUS FIELD 
HEX 0 ERROR FIELD 


Since there are three dummy arguments in the macro routine, the watchdog timer call statement 


must transmit three actual arguments, as follows: 


Argument 1: The first argument specifies the user program address to which IOCS is to 


return control when the watchdog timer service has been performed. 


Argument 2: | The tag assigned to the parameter list. This argument may consist of six 


characters or less, the first of which must be alphabetic. 


Argument 3: The request code, which may be one of the following: 
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Code Requested Service 


] Requests that IOCS reset the watchdog timer. The watchdog 
timer must be reset once every 34 seconds or automatic pro- 
gram restart will occur. 


2 Requests the monitor to start the watchdog timer under pro- 
gram control and automatically initialize the counter to zero. 


3 Requests the monitor to turn off the watchdog timer under 
program control. 
NOTE 


Code 3 should be issued only in 
. special cases, since it causes 
/ the watchdog timer to be totally 
disabled. | 


4 Requests that the monitor read the power status and return the 
reading to the power status field in the specialized routine. 


Other Any code other than one of the above is illegal and will cause 
the monitor to return an illegal request code of 1 to the Error 
Field defined in the last statement of the WDTMSC routine. 
No watchdog timer action is taken when an illegal code is issued. 


When the watchdog timer routine is called, the Assembler substitutes the actual arguments in the 


call statement for the dummy arguments to produce a specialized routine. 


At program execution time, control passes to the l1OCS monitor, and the specified timer action 


is performed. 


2.11 Device Sensing (DVSMSC) Macro Routine 


The DVSMSC user macro routine effects specialization of the statements required to request the 
IOCS monitor to sense the status of a specific device. The generalized coding of the device sensing 


macro routine is shown below. 


? DVSMSC 


MSC MONITOR SERVICE CALL 
DEC 5 DEVICE SENSING CODE 
ADC (1) RETURN ADDRESS 
ADC (2) PARAMETER LIST ADDRESS 
(2) HEX 00(3) © LUN NUMBER 

HEX 0 STATUS FIELD 
HEX 0 ERROR FIELD 

END 


Since three dummy arguments appear in the macro routine, the user call statement must transmit 


three actual arguments, as follows: 
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Argument I: The calling program address to which IOCS is to return control when 


the device sensing service has been performed. 


Argument 2: The address of the parameter list, which becomes the operand of the 
second ADC statement and the label of the HEX statement that defines 
the logical unit number (LUN) of the device to be tested. This argument 
may consist of six characters or less, the first of which must be 


alphabetic. 
Argument 3: The LUN of the device whose status is to be sensed. 


When the call statement is processed, the Assembler inserts the actual arguments in the place of 


the three dummy arguments to produce the specialized routine. 


When the routine is executed, the device's hardware status is returned to the status field, unless 
an erroneous LUN (i.e., an unassigned LUN) was specified, in which case an error code of 2 is 


returned to the error field. If no error occurred, the error field setting remains all zeros. 


2.12 CICMSC Macro Routine 


The CICMSC user macro routine effects specialization of source statements required to test or 
reset busy or off-line bits of devices attached to the Channel Interface Controller (CIC). The 


generalized coding of the routine is shown below. 


? CICMSC 
MSC MONITOR SERVICE CALL 
DEC 4 CIC CODE 
ADC (1) RETURN ADDRESS 
ADC (2) PARAMETER LIST ADDRESS 
(2) HEX 00(3) LUN NUMBER 
DEC 000(4) REQUEST CODE 
HEX 0 STATUS FIELD 
HEX 0 ERROR FIELD 
END 


Since there are four dummy arguments in the macro routine, the call to the routine must transmit 


four actual arguments, as follows: 


Argument |: The calling program address to which IOCS is to return control when the 


CIC service has been performed. 


Argument 2: The address of the parameter list, which becomes the operand of the second 
ADC statement and the label of the HEX statement that defines the logical 
unit number (LUN). This argument must be six characters or less, the 


first of which must be alphabetic. 


Argument 3: The LUN of the CIC device to be tested. 
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Argument 4: The request code, which may be one of the following: 


Code | Requested Service 
l Requests that the busy bit of the specified device be tested and 


set. The current status of the busy bit is returned in bit 0 of 
the status field, where a 1 = busy and a 0 = not busy. The re- 
maining bits of the status field are undefined. The busy bit is 


then set. 
2. Requests a resetting of the busy bit of the specified device. 
3 Requests that the off-line bit of the specified device be 


tested and set. The current status of the off-line bit is re- 
turned in bit 0 of the status field, where 1 = off-line and 

0 = on-line. The remaining bits of the status field are un- 
defined. The device off-line bit is then set. 


4 Requests a resetting of the off-line bit of the specified device. | 


Other Any code other than one of the above is illegal and will be 
reported via a 1 code in the error field defined in the last state- 
ment of the CICMSC routine. No other action is taken by IOCS 
when an illegal request code is specified in position 4 of the 
call statement. | 
When the $CICMSC call statement is processed the Assembler inserts the actual arguments in the 


place of the four dummy arguments to produce the specialized routine. 


When the routine is executed the specified action is taken unless an erroneous LUN (i.e., an 
unassigned LUN) was specified, in which case an error code of 2 is returned in the error field. If no 


error occurred, the error field setting remains all zeros. 
213 TT2260 Macro Routine 

This routine causes the 2260 Translate Table to be inserted in the calling program. The table 
contains the conversions codes to be used by the device controller to translate 2260 keyboard code to 
the ASCII code used internally in the PTS-100. The macro routine coding, shown in Figure 4-11 
contains a dummy argument in the label field of the first statement. The call statement to the routine 
must therefore transmit a label to be identified as the starting location (i.e., the Translate Table base 


address) in the user's program. 


Assume that the symbolic tag TRNS1 is to be used as the base address of this Translate Table in 


the user's program. The call statement 
$ TT2260 TRANS| 

will cause the first starement of the routine to be specialized as follows: 
TRANSI HEX 0000 


The remainder of the Translate Table will be inserted in the calling program. 
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27772260 
SKIP p 


* es i Bete AM ae ot ah ld cB. 


Bite ek te et EHR ERR AHEEKEAEEKREKEKAKKRKKEN KKK 
® ’ . 


te SOFTWARE TRANSLATE TABLE 2260 
ww 
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(2}-- -HEX- - BaAe- - | 
HEX ABNC TAB START 
HE X FASA RETURN Z 
HE X 5958 Y xX 
HE X 5756 W V 
HE X 5554 uJ T 
HE X 5352 5 R 
HE X 5150 Q p 
HE Xx 4F4E 0 N 
HEX 4D4C M L 
HEX 4B4A K J 
HE Xx 4948 I H 
HEX - 4746 G F 
HE X 4544 E ) 
HE X 4342 Cc B 
HEX 41a0 A 
HE X ANAA 
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Figure 4-11. Generalized Coding of the TT2260 Macro Routine 
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2.14 TTASCI Macro Routine 


This routine causes the ASCII Keyboard Translate Table to be inserted in the calling program. The 
table contains the conversion codes to be used by the device controller to translate ASCII keyboard input 
code to the ASCIE code used internally in the PTS-100. The macro routine coding, shown in Figure 
4-12, contains a dummy argument in the label field of the first statement. The call statement to the 
routine must therefore transmit a label to be identified as the starting location (i.e., the Translate 


Table base address) in the user's program. 
The call statement 


$ TTASCI ASCTRN 
will cause the first statement of the routine to be specialized as follows:. 
ASCTRN HEX 0000 


The remainder of the table will be inserted in the calling program. 
2.15 TTIPAR Macro Routine 


This macro routine causes the IPARS Keyboard Translate Table to be inserted in the calling pro- 
gram. The table contains the conversion codes to be used by the device controller to translate IPARS 
keyboard input code to the ASCII code used internally in the PTS-100. The macroroutine coding, shown 
in Figure 4-13, contains a dummy argument in the label field of the first statement. The call statement 
to the routine must therefore transmit a label to be identified as the starting location (i.e., the Trans- 


late Table base address) in the user's program. The call statement 

$. TTIPAR IPRSIN 
| will cause the first Pre of the routine to be specialized as follows: 
IPRSIN | HEX 0000 


The remainder of the table will be inserted in the calling program. 
2.16 Baudot to ASCII Converter Macro Routine 


This routine performs the processing required to convert the five- bit Baudot code input via the 
ASR 32 teletype device to the seven-bit ASCII code used internally in the PTS-100. If this macro 
routine is to be called, the following calling sequence must be established via source code in the 


calling program: 


LAX2 TAG “LOAD POINTER TN PARAMETER LIST 
JMP.N TAGS GO TO CONVFRSION ROUTINE 
TAG ADC INPUT INPUT BUFFER POINTER = RBAUDOT CODE 
ADC OUTPUT OUTPUT BUFFER = WHERE TO PUT ASCII 
HE xX XX XX NUMBFR OF BAUDOT CHARACTERS TO BE XLMTFN 
RESV,@ 2 NUMRFR OF ASCII CHARACTERS 
RESV,@ 2 ERROR WORD 
TAGS ADC #JVBAC POINTER TO CONVERSION ROUTINE 
EXREF #JVBAC EXTERNAL REFFRFNCE STATEMENT FOR #&JVRAC 
JMP TAG? RETURN AFTER CONVERSTON 
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?7TTASCI 
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TABLE ASCII 


Wee RARER AERA KE EHR E HH N HHH KA KEKE KKK HEE 


SKIP fs) 
* 
* SOFTWARE TRANSLATE 
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(1) HE x ABAA 
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HE x 5756 
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HE X AAAG 
HE X ABAD 
HE X ana 
HEX AnAB 
“HEX ABA 
HE x AGB7B 
HE Xx OFPE 
HE X 2D2C 
HE xX 385C 
HEX 3938 
HEX 3736 
HE X 3534 
HE X 3332 
HE X 3134 
HEX 3F OG 
HE X 22A0 
——— = HE------ ASB 
HEX 282A 
HEX 2627 
HE X 2524 
HE X 2322 
HE X 2129 
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HE Xx 4808 
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HE X FAEC 
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——————_ HEX ————"__ FH EE 
HEX EAF2 
HEX F4ad 
HEX 2000 
- END. 


Figure 4-12. 


OVERLINE 
EXCLAMATION 


= z< 


POTNAHWATPIIDAMNA 


CLOSE BRACE 
CLOSE RRACKET 


/ SLANT 
~ HYPHEN 
SEMICOLON 


= GUI N O 


QUESTION MARK 
QUOTATION MARK 

OPEN PAREN 

# AMPERSAND 
PERCENT 

a NUMBER SIGN 
EXCLAMATION 


ENTER 
BE AE REM FE — 

CANCEL 

ROLL DOWN 

ERASE EOL 

STORE=RESTORE 

UP ONE CHAR 


LEFT ONE CHAR 
INSERT CHAR 
SPACE 


~-€LEAR 


FQUALS 


DBVUNTArZ2zaveAa<c en 


REVERSE SLANT 


+ PLUS 


OPEN RRACE 
« PERIOD 
COMMA 
REVERSE SLANT 


SNA AH D 


OPEN -BRACKET 
* ASTERISK 
' APOSTROPHE 
DOLLAR SIGN 
* COMMERCIAL AT 


CLOSE PAREN 


PRINT 


ROLL UP 

ERASE EOS 

TAB 

RIGHT ONE CHAR 
DELETE CHAR 


= HME 2 ee 


DOWN ONE CHAR 


Generalized Coding of the TTASCI Macro Routine 
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Figure 4-13. Generalized Coding of the TTIPAR Macro Routine 
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Note that the input buffer contains the Baudot code to be converted to ASCH code and stored in the 
output buffer. All Baudot data characters are directly convertible to ASCII characters. Thatis, a 
one-for-one conversion of data characters is performed. In addition to data characters, the input 
buffer contains shift characters. The shift characters are used by the Converter routine to perform 
the conversion, but are not written into the output buffer. Hence, the output buffer need not be any 
larger than the input buffer, and may in fact be smaller by the number of shift characters transmitted 
from the ASR 32 teletype to the input buffer. If the programer wishes, he may use the same buffers 
for input and output, thus overlaying the Baudot input with converted ASCII code. 


Normal termination of the Baudot to ASCII Converter Routine may be specified in one of the follow- 


ing ways: 


1. Specifying the exact number of input bytes to be processed in the operand field of the HEX 
statement (i.e., in the third word of the parameter list which starts with TAG in the calling 


sequence code). 
2. Storing a flag of X'FF' in the last byte of the input (Baudot) buffer. 


3. Ifa separate buffer is used for output, storing a flag of X'FF'' in the last byte of the 
ASCII buffer. 


If the Baudot byte count is specified in the HEX statement, the routine will return control to the 
calling program when the specified number of inptt characters has been translated. Ifa flag of X'FF' 
is used in either of the input or output buffers, the routine will discontinue processing when the flag is 
encountered, unless the byte count is satisfied before the flag is found. That is, if the flag termination 
is to be used, the HEX statement should specify the hexadecimal value FF FF so that the byte count 


will never be satisfied before the buffer flag is encountered. 


The actual character value of Baudot code appears in the right-most five bit positions of the input 
byte. The upper, or left-most, three bits indicate whether the code was input from the teletype key- 
board (i.e., the first three bits are zeros) or from the high speed paper tape (i.e., the first three 
bits are ones). The conversion routine zeros these three bits and performs the conversion on the 


valid five bits of the input Baudot bytes. 


The Baudot to ASCII converter routine contains the translate table of ASCII codes to be used in 


performing the conversion. 


To call the converter routine, the programer writes the call statement 


$ #IMBAC 
in his source program. Since no dummy arguments are used in the macro routine coding, no actual 


arguments are required in the call statement. The entire converter routine will be incorporated in the 


calling program at assembly time. 
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At execution time, the calling sequence will be performed and control transferred to the assembled 
converter coding. When the conversion is completed, control will return to me seventh word in the 


calling program! Ss parameter list. 
2.17 ASCII to Baudot Converter Macro Routine 
This user macro routine performs the processing required to convert the seven-bit internal ASCII 


code to the five-bit Baudot code for output to the ASR 32 teletype device. If this macro routine is to be 


called by a user program, the calling sequence must be established in the calling progtam as shown 


below. 

LAX2 TAG! LOAD POINTER TO PARAMETER LIST 
JMP,N TAG3 GO TO CONVERSION ROUTINE 

TAGI ADC INPUT INPUT BUFFER POINTER (ASCII CODE) 
ADC OUTPUT OUTPUT BUFFER POINTER (CONVERTED BAUDOT CODE) 
HEX (BYTE COUNT) NUMBER OF ASCIL BYTES TO TRANSLATE 
RESV,O 2 | NUMBER OF BAUDOT BYTES TRANSLATED 
RESV,O 2 | | ERROR WORD 

TAG3 ADC #JQABC POINTER TO STARTING LOCATION IN CONVERTER 
EXREF #JQABC EXTERNAL REFERENCE STATEMENT FOR #JQABC 
JMP TAG2 RETURN ADDRESS IN CALLING PROGRAM 

TAG2 EQU> OR 


Note that the input buffer contains the ASCII code to be converted to Baudot code and stored in the 
output buffer. 


Normal termination of the ASCII to Baudot converter routine occurs when one of the following 


conditions is encountered: 


1. The specified number of input bytes has been processed. 


2. <A flag of X'FF' is encountered in the input buffer. 


Abnormal termination of the converter routine may occur because of one of the following 


conditions: | i: 
1. The input and output buffers are equal in size. 
2. The end of the output buffer was reached before all input code was processed. 


These error condition terminations may be prevented by ensuring that the output buffer is large enough 
to accommodate all of the characters generated by the routine. The total number of characters 

- generated by the routine includes all of the converted Baudot data characters, plus a shift character 
each time the code conversion switches from alpha data to numeric data, or from numeric data to alpha 
data. Thatis, the converter routine outputs a shift character to cause the tclctype to switch from 
upper case to lower case and vice versa when the keyboard position of the current output character 
differs from the previous output character's position on the keyboard. The total number of output 
characters will always include at least one shift character, and could possibly include as many shift 


characters as data characters, thus doubling the output buffer size requirement. 
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In setting up the output buffer area, the programer should reserve a storage space twice the size 
of the input buffer, or estimate the number of shift characters that will be generated and set up an 
output buffer equal to the estimated number of shift characters plus the number of characters reserved 
for the input buffer. If storage space is critical, the programer may conserve space by overlapping 


the input and output buffer in one of the following ways: 


1. Set up a buffer area equal to the estimated maximum number of shift characters plus the 


number of input characters, and then perform the following: 


Set the output buffer pointer at the upper location of the buffer area. 


Set the input buffer pointer below the output pointer at the point equal to the estimated 


number of shift characters. 


Set a termination flag of X'FF' in the last byte of the shared buffer and set the byte count 
in the HEX statement of the parameter list to X'FFFF'. 


2. Set up a buffer area twice the size of the input buffer requirement, then perform the following: 


set the output buffer pointer at the upper location of the buffer area. 
Set the input buffer pointer at the middle of the buffer area. 


Set a termination flag of X'FF' in the last byte of the shared buffer and set the byte 
count in the HEX statement of the parameter list to X'FFFF'. 


When either of the above actions has been taken in the source program, at execution time the 
converter routine retrieves the first input code from the starting input pointer location, converts it, 
and places the output code at the starting output pointer location. As the conversion proceeds, the 
buffer pointers move down each time code is converted. Eventually, the output data and shift char- 
acters write into locations previously occupied by input ASCII code. When the X'FF" flag is en- 
countered, the conversion process terminates and control is transferred to the calling program ait the 


seventh word in the parameter list. 


The ASCII to Baudot converter routine contains the translate table of Baudot codes used in per- 


forming the conversion. 


To call the converter routine, the programer writes the call statement in one of the following 


formats: 


$ #JIMABC Arg,,Arg,,Arg,,Arg, 


or 


$ #JMABC ,,,, 
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The actual arguments in the first call statement specify that error checking statements in the 
generalized macro routine are to be eliminated. That is, dummy arguments of the forms (1Y), (2Y), | 
(3Y), and (4Y), appear in the error checking statements. These arguments specify that the Assembler 
is to omit the statements in which they appear if actual arguments appear in positions l, 2, 3, and 4 
of the call statement list. The actual arguments may be any characters except commas. The actual 


arguments must be separated by commas. 


The second form of the call statement omits the actual argument list via a series of four commas. 
This call statement causes the error checking statements to be included in the specialized routine that 


the Assembler inserts in-line in the calling program. 


The only advantage in using the first form of the call statement is to eliminate approximately 30 
bytes of storage for the error checking statements and to save the time required to process them. 
Since the storage space and execution time requirements are relatively inconsequential, the programer 
is advised to use the second form of the call statement to include the error checking unless storage 


space iscritical. The error checking statements test for the following conditions: 


1. Input and output buffers are equal in size, in which case an error termination will occur, 
indicated by an error code of 1 returned in the error word of the calling program's parameter 
list. 


2. There is no equivalent Baudot code for an ASCII code to be converted,. indicated by an 


error code of 2 returned in the error word of the calling program's parameter list. 


3. . The end of the output buffer was reached before all of the input was converted, in which case 
an error termination will occur, indicated by an error code of 4 returned in the parameter 


list error word, 


If the error checking statements are excluded, no error indicators will be returned to the calling 


program. The converter routine will still terminate, however, when the output buffer is too small 


(i.e., when error conditions 1 and 3 above occur). 


In all cases, the ASCII to Baudot converter routine returns control to the calling program at the 


seventh word of the parameter list. 


2.18 ALIOCS Macro Routine 


The ALIOCS macro routine is a listing of all the input/output coding used by the PTS-100 cassette 


native assembler. The lengthy listing is not included in this handbook since it is used only for assembly. 


2.19 Disc Logical Input/Output Macro Routine 
The Disc Logical Input/Output (LIOCSD) macro routine contains the codiny necessary to carry out 


the actions requested by the disc action and status macros, which are branches to certain routines in 


the Disc Logical Input/Output macro. This is the main processing macro for the disc. 
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The Disc Logical Input/Output macro picks up the File Control Block pointer specified by an 


action or status macro, and uses the fields in that File Control Block both as sources of information 


about the file and as working storage for the processing of the file. 


2.20 Disc File Control Block Description Macro Routine 


The Disc File Control Block Description (FCBD) macro establishes a file control block, a work 


area 100 bytes long, in which the logical input/output maintains all information about the file and the 


current state of its processing. The generalized coding of the File Control Block Description macro 


routine is shown in Figure 4-14, 


Since there are 10 dummy arguments in the routine, the call statement to the routine, must 


transmit 10 actual arguments, as follows: 


Argument I: 


Argument 2: 


Argument 3: 


Argument 4: 


Argument 5: 


Argument 6: 


Argument 7: 


Argument 8: 


Argument 9: 


Argument 10: 


The label of the File Control Block; this label is referred to in all the 


action and status macros to identify the specific file to be accessed. 
A number from 0 to 7, identifying the disc drive on which the file resides. 


Type of buffering. S = single buffer. D = double buffer (may be specified 


only for sequential files). 
First buffer address. 


Second buffer address. (This should be specified as 0 for single 
buffering. ) 


Address of file name, a 10-byte field containing the name that was 
assigned to the file in the Volume Directory by the Disc Allocator 


program. 


Address of error word, a one-word field which will be set to an error 


identifying number if an error occurs in processing this file. 


Relative position of key in record, for direct access. For type K 
random files this gives the byte location, relative to byte 0 of the record, 


of the start of the key field. | 


The number of bytes in the key field. 


‘The length of the buffer, in sectors. This is the number of 320-byte 


sectors that can be read or written at one time, based on the length of 


the buffer(s) provided. 


Each action or status macro contains a pointer to the File Control Block of the file on which 


t is to operate. 
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. Figure 4-14. Generalized Coding of the FCBD Macro Routine. 
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2.21 Disc Action and Status Macros 


The first parameter of every disc action macro is the label of the File Control Block that identifies 
the file to be accessed. This must be the same as the first parameter of the file control block descrip- 


tion macro for that file. 


The action macros are Open, Close, Get, Put, Read, Write, and Delete. Open and Close apply to 
all file types. Get and Put apply only to sequential files. Read, Write, and Delete apply only to random 
files. 


Test and Wait are status macros and do not result in any file accessing. One of the two must be 
used after each of the action macros to assure that one action has been completed before the next one 
is requested. The Test or Wait macro need not follow the action macro immediately but must be 


issued before another action call. 
2.21.1 Open Disc (OPEND) 


The Open macro must be issued before any accessing can be done ona file. It searches for the 
file in the Volume Directory (established by the Disc Allocator utility program), and places in the 
File Control Block various pieces of information describing the file. It also opens the logical unit 


through the IOCS monitor. The generalized coding of the routine is shown below. 


?70PEND 
LAX2 *4+6 
JMP #LDOO, L 
ADC (1) 
TEXT (2)! 
ADC (3) 
END 


Since three dummy arguments appear in the macro routine, the user call statement must transmit 


three actual arguments, as follows: 
Argument 1: The label of-the File Control Block. 


Argument 2: This argument designates the type of open. I = open for input. 


O = open for output. 


Argument 3: . The label of the error exit is specified as argument 3. This is the 
location to branch to if the file cannot be opened. The exact reason 
_ for the failure is indicated by the error word pointed to in the File 
Control Block. 
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2.21.2 Close Disc (CLOSED) 


Ihe Close macro is issued when all file accessing has been completed. For output sequential files 
it causes the last record to be written on the disc, followed by an end of file indicator. If there are 


no other files open, it also closes the logical unit. The generalized coding of the routine is shown below. 


? CLOSED 
LAX2 +6 
JMP #LDCO, L 
ADC * A) 
ADC (2) 
END 


There are two dummy arguments in the Close Disc macro routine: 
Argument 1: The label of the file control block. 


Argument 2: Error exit. This is the location to branch to if an error occurs such 


that the Close process cannot be completed. 
2.21.3 Get (GETD) 


The Get disc macro, applicable only to sequential files, causes the next logical record to be moved 
from the buffer to the specified work area. Buffer switching and disc reads are executed when neces sary. 


The generalized coding of the routine is shown below. | 


?GETD 
LAX2 | +6 
JMP #LDGO, L 
ADC (1) 
ADC (2) 
ADC (3) 
ADC | (4) 
END 


There are four dummy arguments in the Get disc macro routine: 


Argument 1: The label of the File Control Block. 


Argument 2: | The address of the work area into whichthe next record is to be moved. 
Argument 3: End of file exit specifying location to branch to if end of file is found. 
Argument 4: © The label of the error exit. 
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2.21.4 Put (PUTD) 


The Put disc macro, applicable only to sequential files, causes the logical record in the designated 
work area to be moved to an output buffer. Buffer switching and disc writes are executed when 


necessary. The generalized coding of the routine is shown below: 


?PUTD 
LAX2 *+6 
JMP #LDPO, L 
ADC (1) 
ADC (2) 
ADC (3) 
END 


There are three dummy arguments in the Put disc macro routine: 


Argument I: The label of the File Control Block. 
Argument 2: _ The address of the work area from which the record is to be taken. 
Argument 3: The label of the error exit. 


2.21.5 Read (READD) 


The Read disc macro, applicable only to random files, inputs one record from the disc intoa 


specific work area. The generalized coding of the routine is shown below: 


?READD 
LAX2 +6 
JMP #LDRO, L 
ADC (1) 
ADC (2) 
ADC (3) 
ADC. (A) 
TEXT ' (5)! 
ADC (6) 
END 


There are six dummy arguments in the Read disc macro routine: 


ee Lt The label of the File Control Block. 

eee denent as a The address of the work area into vescn the record is to be moved, 
Argument 3: | End -of -file exit. 

Argument 4: | | Uncorrectable error exit. 

Argument 5: | Type spaweeen: D = direct ACCESS. S'= sequential access. 
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Argument 6: Address of direct access parameter list. (This argumentis zero if there 


is no list.) If there is a list, it contains two fields, as follows: 


a. Address of key field. This is the address of the left end of the 
field with which the key in the accessed record is tobe compared. 


The value is zero if there is no key. 


b. Relative address. For K type files this is a relative track 


address; for N type files it is a relative record address. 


2.21.6 Write (WRITED) 


The Write disc macro, applicable only to random files, outputs one record to the disc from a 


specific work area. The generalized coding of the routine is shown below: 


? WRITED 
LAX2 +6 
IMP a #LDWO, L 
ADG. = (1) 
ADC | (2) 
ADC (3) 
ADC (4) — 
END 


There are four dummy arguments in the Write disc macro routine: 


Argument IL: The label of the File Control Block. 


Argument 2: The address of the work area from which the record is to be moved. 


Argument 3: Uncorrectable error exit. 


Argument 4: Address of direct access parameter list, which contains only the 
relative address. For K type files this is interpreted as a relative 


track address; for N type files it is a relative record address. 


2.21.7 Delete (DELD) 


The Delete disc macro, applicable only to random files with keys, locates a specific record in 


the file and marks it deleted by changing its banner word from hexadecimal 0001 to hexadecimal 0000. 


The generalized coding of the routine is shown below: 


?DELD 
LAK? *46 | 
JMP #LDDO, L 
ADC (1) 
ADC (2) 
ADC (3) 
END 
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There are three dummy arguments in the Delete disc macro routine: 


Argument 1; The label of the File Control Block. 
Argument 2: Uncorrectable error exit. 
Argument 3: Address of direct access parameter list. The list contains two fields, 


as follows: 


a. Address of key field. This is the address of the left end of the 


field with which the key in the accessed record is to be compared. 
b. Relative track address. 
2.21.8 Wait (WAITD) 
The Wait disc macro checks whether the last requested action on the indicated file has been 


completed. The Wait macro is applicable to the actions Open, Close, Get, Put, Read, Write, and 


Delete. The generalized coding of the Wait disc macro routine is shown below. 


?WAITD 
LAX2 | *+6 
JMP #LDWAO, L 
ADC (1) 
END : 


The single dummy argument is the label of the File Control Block, 


2.21.9 Test (TESTD) 


Tne Test disc macro provides an alternate means of checking the completion of an action macro, 
without causing a program stall if the action is found to be incomplete. This status macro is applicable 


to the actions Open, Close, Get, Put, Read, Write, and Delete. The generalized coding of the Test 


disc macro routine is shown below: 


?TESTD 
LAX2 *-+46 
IMP #LDTO, L 
ADC (1) 
ADC (2) 
END 


There are two dummy arguments in the Test disc macro routine: 
Argument 1: The label of the File Control Block. 


Argument 2: _ The address of the indicator word. This word is set to l if the last 


action was completed; it is set to 0 if the action was not completed. 
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APPENDIX A 


PTS-100 CHARACTER SET 


APPENDIX A 


PTS-100 CHARACTER SET 


ASCII HEX 
Symbol Hollerith Extended Code 9g ASCIig 8 Bit 7 Bit 
@ 0-2-8 50 | 300 Co 40 
A 12-1 132 301 Cl 41 
B 1Z22 130 302 _ C2 42 
C 12-3 134 303 C3 43 
D 12-4 129 304 C4 44 
E 12-5 | 133 305 C5 45 
¥F 12-6 131 306 C6 46 
G 12-7 135 307 C7 47 
H 12-8 144 310 C8 48 
I 12-9 136 311 C9: 49 
J 11-1 68 312 CA 4A 
K 11-2 66 313 CB 4B 
L 11-3 70 314 cc 4C 
M 11-4 | 65 315 CD 4D 
N 11-5 69 316 CE 4E 
O 11-6 67 317 CF | 4F 
P 11-7 | 1 320 DO 50 
Q 11-8 | 80 321 Di 51 
R 11-9 | 72 323 D2 «52 
5 0-2 34 323 D3. | 53 
L Q-3 38 324 _ D4 54 
U 0-4 33 | 325 D5 55 
Vv 0-5 37 326 Do . 56 
W 0-6 35 , 327 D7 57 
Xx 0-7 39 330 . D8 58 
a 0-8 48. 331 Dy * oo 
Z 0-9 40. 332 | DA 5A 
[ 12-5-8 149 _ 333 DB 5B 
\ 0-6-8 | 51 334 DC 5C 
] 11-5-8 : 85 335 DD — 5D 
1 7-8 23 . 336 DE 5 
- 2-8 18 337 DF op a 
blank No Punch 00 | 240 AQ 20 
' 11-2-8 82 241 Al 21 
: 0-5-8 53 242 Az 22 
it 0-7-8 55 243 A3 23 
$ 11-3-8 86 244 A4 24 
% 11-7-8 87 245 A5 | 25 
& 12-7-8 — 15] 246 Ab 26 
j 4-8 17 247 A7 27 
( 0-4-8 | 49 250 A8 28 
) 12-4-8 145 = 251 AY 29 
* 11-4-8 81 252 AA ZA 
+ 12 : 128 253 AB 2B 
‘y 0-3-8 54 254 AC 2C 
- 1] | 64 | . Asis AD | 2D 
12-3-8 150 256 | AE 2E 
/ O-l 36 257 | AF — 2F 
0 0 320 C—O 260 BO 30 
J 1 4 261 Bil 31 
2 ys) Z 262 B2 32 
3 3 6 263 B3 33 
4 4 ] 264 | B4 34 
5 5 5 265 R5 | 35 
6 6 3 266 Bo | 36 
7 7 7 267 B7 37 
8 8 16 270 B8 a 38 
9 9 8 
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